This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Huge slowdown since 6.0
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