Re: Huge slowdown since 6.0

[Elena Zannoni <ezannoni@redhat.com>]

Daniel Jacobowitz writes:
 > On Fri, Feb 20, 2004 at 11:37:48AM -0500, Elena Zannoni wrote:
 > > 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.
 > 
 > OK, I'll post it to gdb-patches and check it in, later today.
 > 
 > What numbers would you like besides these?  I can generate anything else
 > you're interested in.
 >   http://sources.redhat.com/ml/gdb/2004-02/msg00236.html
 > 
 > The list padding makes those numbers inexact, but the gist is: about
 > 3200 global symbols with enumerators static, and about 700,000 with
 > them global.

yeah, these ones. Wow.