Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz <drow@mvista.com>]

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.

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer