This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: DW_AT_specification and partial symtabs
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