Re: RFA: Don't use obsavestring in dwarf2read

[Elena Zannoni <ezannoni at redhat dot com>]

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.