From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26034 invoked by alias); 5 Feb 2004 19:48:23 -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 26026 invoked from network); 5 Feb 2004 19:48:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Feb 2004 19:48:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AopU5-0007zq-9W; Thu, 05 Feb 2004 14:48:21 -0500 Date: Thu, 05 Feb 2004 19:48: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: <20040205194821.GA30363@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16418.39156.566837.685666@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00105.txt.bz2 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. > [BTW why are only few obstack properly initialized?] Which do you mean? > 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. 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer