Re: Huge slowdown since 6.0

[Andrew Cagney <cagney@gnu.org>]

> Daniel Jacobowitz writes:
>  > How can they possibly be to blame?  Well, they are.  And reverting the
>  > change for enumerators definitely won't do any harm.  Take a look at
>  > this, read it two or three times if necessary - it took me about a
>  > dozen:
>  > 
>  > > > -                          &objfile->static_psymbols,
>  > > > +                          cu_language == language_cplus
>  > > > +                          ? &objfile->static_psymbols
>  > > > +                          : &objfile->global_psymbols,
>  > 
>  > If I swap "static" and "global", it reduces GDB startup time by roughly
>  > 40% for glibc with debug information, which contains a lot of C
>  > enumerators.  I assume that is what you meant to do in the first place?
>  > If so I can recover the speed hit for C for GDB 6.1, and then address
>  > the larger issues with large numbers of global psymbols in HEAD after
>  > we branch.
> 
> Another point in favor of the theory that conditional expressions are
> bad.
> 
> This should be fine, consider it preapproved. However, what you are
> really saying is that qsort performance is really bad in case we have
> lots of symbols to sort. But how many symbols? You didn't post the
> numbers.

Hmm, begs a few questions:

- why do we load the symbols during startup?
Load globals on demand?
- 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?

Andrew