Re: [RFA/dwarf] Allocate abbrevs from a new obstack

Daniel Jacobowitz
2004-02-26T23:05:18Z

On Thu, Feb 26, 2004 at 05:22:21PM -0500, Elena Zannoni wrote:
> Jim Blandy writes:
> >
> > Daniel Jacobowitz <drow@false.org> writes:
> > > Another independent performance optimization from my profiling. This one is
> > > good for several percent speedup on mainline. My original description:
> > >
> > > - It plugs a huge memory leak. After loading partial symbols for
> > > libc, GDB uses 5.6MB memory without this patch and 1.6MB with it.
> > > We weren't emptying the abbrev table.
> > >
> > > [Specifically, we were emptying it after dwarf2_build_psymtabs_hard,
> > > instead of once each time through the loop. dwarf2_read_abbrevs then
> > > zeroed out the allocated, unreferenced pointers.]
> > >
> > > - I spent a lot of time trying to find alternate data structures that
> > > would be more efficient. The expandable hash table is slower, even if
> > > you initially allocate it to the right size. The splay tree I expected
> > > to be quite good in this case, but it isn't either; the overhead is simply
> > > too high. The fixed-size ad-hoc hash table appears to be the best we can
> > > do.
> > >
> > > Tested on i686-pc-linux-gnu, no regressions. OK to commit?
> >
> > Looks great --- please do.
>
> Jim, there was agreement to not touch these central files until after
> the branch.

Was there? The closest I saw was an agreement not to merge intercu
support. This patch is not particularly important, or the other
optimization patch, but they are independent of that. I would like to
see the duplicate symbols patch reviewed before the branch.

In any case, I won't commit this one until after the branch - which I
think is coming up in about an hour.