This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Huge slowdown since 6.0


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.

Hmm, begs a few questions:


- why do we load the symbols during startup?
Load globals on demand?
- why do we sort the symbols during startup?
Use a hash (so that break main is fast) and sort when (break main<tab> is entered?)
- why don't we do more while GDB is twiddling its thumbs in the event loop event loop?


Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]