Re: DW_AT_specification and partial symtabs

[Andrew Cagney <ac131313 at redhat dot 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.

So we agree, 25% is significant but 3% is not.

A better question is what % of symtabs get draged in by a C++ `break 
main; run'.  Wasn't the original conjecture that symtabs get sucked in 
anyway so why do it twice.

Remember, as we've discovered with threads, users define ``GDB is slow 
to start'' differently to us as GDB developers.  We think of it as:

	$ gdb program
	(gdb)

but the user appears to be more focused on things like:

	(gdb) break main

and:

	(gdb) run
	Break point main reached
	(gdb)

The first can be really badly fudged by not even loading the [p]symtab . 
 Just makes `break main' a bit slow :-)

So, we really don't know what symtab info is critical to GDB.  An 
uneducated guess, based on ``break main; run'' is:

	- addr -> line
	- function/symbol -> addr
	- addr -> symbol

Andrew