Re: DW_AT_specification and partial symtabs

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jun 13, 2003 at 11:38:38AM -0400, Andrew Cagney wrote:
> Daniel wrote:
> 
> 
> > > 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. 
> 
> I think that's an understatement.

Not really.  You can subtract the psymtab time from the combined time,
and then compare.  It still more than triples the time.

> Elena wrote:
> 
> >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.
> 
> Some back of envelope caculations are in order.
> 
> ``(gdb) print sizeof (struct ...) indicates that sizeof(symtab) ~= 
> 2*sizeof(psymtab) so GDB is burning 33% of allocated memory.  Assuming 
> memory and file I/O are the bottle neck, slashing 33% of memory should 
> slash 33% of the time.
> 
> I just hope GDB isn't doing something stupid like searching psymtab 
> before symtab.

That neglects type information, which we don't really build during
psymtab reading, and is a huge memory sink.

> > > 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.
> 
> I think oprofile data would be far more useful - remember the thread 
> problem where the profile data (and its suggested micro-optimizations) 

Ah, but you can back-of-the-envelope simulate this easily without
oprofile.  Build without -pg, use maint set profile.  It does only flat
profiling using a timer, and is fairly accurate.

> were totally bogus.  But having said that, wasn't there a proposal to 
> fix/rewrite BFD's mmap interface?

Yes, but who knows when it'll happen.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer