Re: Huge slowdown since 6.0

[Daniel Jacobowitz <drow@false.org>]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer