This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: DW_AT_specification and partial symtabs
Daniel Jacobowitz writes:
> On Thu, Jun 12, 2003 at 03:16:58PM -0700, David Carlton wrote:
> > On Thu, 12 Jun 2003 13:26:51 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> >
> > > I wonder, if we are not reaching the end of the usefulness of the
> > > psymtabs. I mean, if we start making the psymtab reader behave like
> > > the symtab reader, how much faster is that going to be, how much
> > > smaller, etc.
> >
> > Yeah, I'm starting to wonder that, too. This particular situation is
> > enough of an edge case that I'm actually tempted not to fix the
> > psymtab reader until I get bug reports from users complaining about
> > it, because if I do fix it completely then I'll probably make the
> > psymtab reader slow, make it duplicate lots and lots of the
> > functionality of the symtab reader, and do it in such a way as to
> > cause code duplication that will lead to bugs as the two versions slip
> > out of sync. So I'm tempted to let things be for now, and wait until
> > .debug_pubtypes comes along to save the day.
> >
> > I guess another possibility would be to merge the symtab reader and
> > psymtab reader, and have there be some variable 'reading_psyms' or
> > whatever to control what sort of symbols we're creating, how deeply we
> > descend into trees, etc.
> >
> > It would be interesting to find out the following:
> >
> > 1) How much is the savings for building a psymtab vs. building a
> > symtab?
> >
> > 2) Where is that savings coming from?
> >
> > If the savings largely comes from not descending into the bodies of
> > functions, then the current structure should go: we should just merge
> > the psymtab and symtab readers, but have some flag floating around
> > that controls whether or not we descend into bodies of functions.
>
> 1) is very easy to measure. GDB has a command line option --readnow
> which forces symtabs to be read in immediately. I tried my normal
> performance testcase: a dummy main() linked to all of mozilla's
> component libraries, with full stabs debug info. Note stabs, not
> DWARF2, so the timing may vary. Also note that we duplicate psymtab
> and symtab creation doing it this way, so it overestimates the cost.
> But it should give you an idea.
>
> Psymbols 5.3:
> gdb --batch -x a ./mozilla-libs 17.34s user 1.72s system 78% cpu 24.160 total
>
> Psymbols and symbols 5.3:
> gdb --batch -x a ./mozilla-libs --readnow 41.20s user 4.93s system 83% cpu 55.207 total
>
> Psymbols CVS:
> /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs 8.79s user 1.01s system 99% cpu 9.850 total
>
> Psymbols and symbols CVS:
> /opt/src/gdb/x86-as/gdb/gdb --batch -x a ./mozilla-libs --readnow 30.45s user 2.70s system 94% cpu 35.131 total
>
> Note that none of those times is really acceptably fast, IMHO. Probably
> they all can be improved. Looking at profiling data I see about three
> seconds we can knock off the symbol reader and there are almost
> certainly more.
But with --readnow we do both psymtabs and symtabs. I wonder, if we
didn't do psymtabs at all, the time would improve, one hopes.
And the memory footprint would shrink too.
>
> Andrew's suggested in the past that (rather than all-at-once) we read
> symbols lazily; that's essentially like the status quo but without a
> separate psymtab table. I don't know how much that saves us.
>
> Keep in mind that symbols are (at present) rather memory-intensive
> compared to psymbols. Also keep in mind that we build more type
> information when reading symbols - more time, more memory.
>
> One quick thing we can do to speed up DWARF2 symbol reading is to
> finish converting the rest of GDB to runtime-computed locations; then
> we won't have to parse location lists or location expressions at
> load time.
>
yes, that's a clear win.
elena
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer