Re: Huge slowdown since 6.0

[Andrew Cagney <cagney@gnu.org>]

>  > Hmm, begs a few questions:
> 
> sorry, I am talking about partial symbols. It's not clear from the above.

[psymbols, symbols, same question :-)]

>  > 
>  > - why do we load the symbols during startup?
>  > Load globals on demand?

Daniel wrote:
> What sort of demand do you have in mind?
The very first lookup_symbol_by_name().

At present core gdb contains significant chunks of logic intended to out 
wit the symbol table.  core-gdb should instead just ask for exactly what 
it needs and let the symbol table decide if/when something should be 
pulled in.

>  > - why do we sort the symbols during startup?
>  > Use a hash (so that break main is fast) and sort when (break main<tab> 
>  > is entered?)
>  > - why don't we do more while GDB is twiddling its thumbs in the event 
>  > loop event loop?

Daniel writes:
> Hmm.... that's pretty complicated to implement.  It would require doing
> things in small chunks and handling interruption gracefully.  The
> problem is, at the first symbol lookup, we will probably need to have
> all the symbols...

The current behavior isn't too friendly either mind.  Given a slow 
loading symbol table the users only option is "take an early lunch". 
Cntrl-c, if it worked, would just abort the load :-(

Even if we start out with on-demand, it should work better.  Given:

	$ gdb foo
	(gdb) break main
	(gdb) run

why is GDB loading glibc's symbols?

> The thing that I am curious about is to see how early into a regular
> debug session we build the symtabs. I.e. I am afraid that any
> reference to any symbol from the command line makes the whole lot
> expand anyway. The answer to this may help answer the question whether
> we really need a two tier symbol table system, or if there is another
> way of solving the same problem. While cleaning up the obstack stuff,
> it became obvious that the intent was for the psymtabs to go away once
> expanded into full symtabs, but this was never implemented.

enjoy,
Andrew