Re: Huge slowdown since 6.0

[Elena Zannoni <ezannoni@redhat.com>]

David Carlton writes:
 > On Fri, 20 Feb 2004 00:09:06 -0500, Daniel Jacobowitz <drow@false.org> said:
 > > My testcase is in C.
 > 
 > > These are all conditionalized on language_cplus.
 > 
 > > 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?
 > 
 > Um, yeah.  Oops.  That would qualify as an obvious fix.
 > 
 > There's one other interesting point here - where exactly is the
 > slowdown coming from?  After all, we generate the same number of
 > searches, and lookup_symbol can potentially look at all the static
 > psymbols just like it could look at all the global psymbols.  Not only
 > that, but looking at the static psymbols is vastly slower than looking
 > at the global psymbols (for no good reason, as far as I know, but
 > that's a separate issue; lookup_partial_symbol has issues).
 > 
 > But I suppose the point is that looking at all the static psymbols is
 > only a very last resort in lookup_symbol, so (as long as the symbol
 > you're looking for actually exists) it wouldn't get called very often.
 > 
 > Or is there something else that I'm missing?

No lookup yet. Only reading the debuginfo and sorting *only the globals*.
Daniel profiled only the reading of the psymbols part.

It threw off me for a while, before I remembered that we only sort the
globals psymbols.