From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11357 invoked by alias); 5 Feb 2004 19:29:46 -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 11350 invoked from network); 5 Feb 2004 19:29:45 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 5 Feb 2004 19:29:45 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id A07081A4412; Thu, 5 Feb 2004 14:26:44 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16418.39156.566837.685666@localhost.redhat.com> Date: Thu, 05 Feb 2004 19:29:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read In-Reply-To: <20040202182218.GA3405@nevyn.them.org> References: <20040112015726.GA7151@nevyn.them.org> <20040202182218.GA3405@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00104.txt.bz2 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? [BTW why are only few obstack properly initialized?] How do you get to 30% savings from these changes?