Re: RFA: Don't use obsavestring in dwarf2read

[Elena Zannoni <ezannoni at redhat dot com>]

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?