Re: DW_AT_specification and partial symtabs

[Elena Zannoni <ezannoni@redhat.com>]

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