This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/dwarf] Allocate abbrevs from a new obstack
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>,gdb-patches at sources dot redhat dot com, Elena Zannoni <ezannoni at redhat dot com>
- Date: Thu, 26 Feb 2004 17:22:21 -0500
- Subject: Re: [RFA/dwarf] Allocate abbrevs from a new obstack
- References: <20040225035543.GA13672@nevyn.them.org><vt2ad35lcgv.fsf@zenia.home>
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.