From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28928 invoked by alias); 5 Feb 2004 20:37:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28921 invoked from network); 5 Feb 2004 20:37:32 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Feb 2004 20:37:32 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 8F8481A4412; Thu, 5 Feb 2004 15:34:30 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.43222.486879.784465@localhost.redhat.com> Date: Thu, 05 Feb 2004 20:37:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read In-Reply-To: <20040205194821.GA30363@nevyn.them.org> References: <20040112015726.GA7151@nevyn.them.org> <20040202182218.GA3405@nevyn.them.org> <16418.39156.566837.685666@localhost.redhat.com> <20040205194821.GA30363@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00108.txt.bz2 Daniel Jacobowitz writes: > On Thu, Feb 05, 2004 at 02:26:44PM -0500, Elena Zannoni wrote: > > Daniel Jacobowitz writes: > > > On Sun, Jan 11, 2004 at 08:57:26PM -0500, Daniel Jacobowitz wrote: > > > > This patch is pretty self-explanatory, and pretty effective: With -readnow > > > > to force immediate loading of full symbols, this is good for 3% startup time > > > > and 30% memory savings (that's 100MB out of 330MB!) for a gdb session > > > > against "monotone". We already rely on the lifetimes of this data, so > > > > there's no point in duplicating it onto another obstack with the exact same > > > > lifetime. > > > > > > > > OK? > > > > > > > > [My current C++ work may have significant memory and startup time impact. > > > > I'm trying to clean house at the same time, so that I don't introduce a net > > > > loss. This is low-hanging fruit; higher-hanging fruit will take somewhat > > > > longer.] > > > > > > Updated for Michael's comments, and to fix merge issues (and a new > > > introduction of obsavestring). I also updated the leading comment to > > > mention that symbols and types can now point into each other's > > > obstacks. > > > > > > I am not comfortable with this micro-optimization. > > > > The purpose and design of the objfile obstacks would become confusing. > > TYPE_TAG_NAME, for instance, would be now allocated on the > > type_obstack in all files except for dwarf2read.c. And the > > crosspollination between different obstacks also is perplexing. I > > don't think that assuming that they will always have the same lifetime > > is safe, given they are intentionally separate. > > > > However you do raise some good points. Do we need 3 separate obstacks for > > each object file? If they all have the same lifetime, maybe not. > > Also are the obstacks a good idea in general? > > The obstacks themselves are probably a good idea. Once upon a time, > Peter informed me, there was a plan to free the psymbol obstack when > all symbols had been read in; but that doesn't seem like a useful > optimization, and I can't think offhand of any use for separate symbol > and type obstacks. I wouldn't object to having a per-objfile obstack > instead, and un-seperating them. I think it would be worthwhile to see how much doing that would save us. > > > [BTW why are only few obstack properly initialized?] > > Which do you mean? > I grepped for obstack_init, and only a few obstacks call that function. Form the obstack doco, it seems that it needs to be called. I wonder if the function was introduced later on in libiberty, as an afterthought. > > How do you get to 30% savings from these changes? > > Take a look at how much of the memory usage of GDB on a large C++ > application is for storing names. For monotone, .debug_str is almost > three times the size of .debug_info, at a whopping 40MB. That's where > the biggest savings comes from: using pointers directly into > .debug_str. Because of the GNU LD string merging optimizations, that > probably accounts for 80MB or so of the savings. > Ah, ok, it's because of the nature of the program you were handling. I was trying to imagine how the overhead of obstack themselves could be that large. It seems to me that this is a good argument for an 'on demand' symbol reading implementaion. But, yes the various dwarf2 sections are already in the psymbol_obstack. And we are duplicating that again on the type_obstack. :-( > Another large portion comes from not duplicating the names of types in > the typedef symbols associated with the type. One was on type_obstack, > the other on symbol_obstack. > Right; this would also go away if we unify the obstacks.