From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5983 invoked by alias); 5 Feb 2004 20:47:58 -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 5975 invoked from network); 5 Feb 2004 20:47:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Feb 2004 20:47:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AoqPk-0002Oq-UK; Thu, 05 Feb 2004 15:47:56 -0500 Date: Thu, 05 Feb 2004 20:47:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read Message-ID: <20040205204756.GA2465@nevyn.them.org> Mail-Followup-To: Elena Zannoni , gdb-patches@sources.redhat.com References: <20040112015726.GA7151@nevyn.them.org> <20040202182218.GA3405@nevyn.them.org> <16418.39156.566837.685666@localhost.redhat.com> <20040205194821.GA30363@nevyn.them.org> <16418.43222.486879.784465@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16418.43222.486879.784465@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00109.txt.bz2 On Thu, Feb 05, 2004 at 03:34:30PM -0500, Elena Zannoni wrote: > > 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. Well, it wouldn't save anything by itself - there's immeasurable overhead to the obstacks. It would let us eliminate this sort of duplication, but they're pretty tricky to identify; it took me a couple of hours to convince myself about this set of 'em. > > > [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. It looks like obstack_specify_allocation and obstack_init fill the same role. The objfile's obstacks use the former. > 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. :-( Right. I'm not sure how much of this can be done on demand that isn't already; if I wasn't clear about this, the 100MB was a worst-case number (-readnow). Without -readnow it's much less. > > 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer