Re: RFA: Don't use obsavestring in dwarf2read

Elena Zannoni
2004-02-05T19:29:46Z

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?