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