Re: Huge slowdown since 6.0

[Elena Zannoni <ezannoni at redhat dot com>]

Andrew Cagney writes:
 > > 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:

sorry, I am talking about partial symbols. It's not clear from the above.

 > 
 > - 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?

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.