Re: RFA: Don't use obsavestring in dwarf2read

[Daniel Jacobowitz <drow at mvista dot com>]

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