This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Huge slowdown since 6.0
David Carlton writes:
> On Fri, 20 Feb 2004 00:09:06 -0500, Daniel Jacobowitz <drow@false.org> said:
> > My testcase is in C.
>
> > These are all conditionalized on language_cplus.
>
> > 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?
>
> Um, yeah. Oops. That would qualify as an obvious fix.
>
> There's one other interesting point here - where exactly is the
> slowdown coming from? After all, we generate the same number of
> searches, and lookup_symbol can potentially look at all the static
> psymbols just like it could look at all the global psymbols. Not only
> that, but looking at the static psymbols is vastly slower than looking
> at the global psymbols (for no good reason, as far as I know, but
> that's a separate issue; lookup_partial_symbol has issues).
>
> But I suppose the point is that looking at all the static psymbols is
> only a very last resort in lookup_symbol, so (as long as the symbol
> you're looking for actually exists) it wouldn't get called very often.
>
> Or is there something else that I'm missing?
No lookup yet. Only reading the debuginfo and sorting *only the globals*.
Daniel profiled only the reading of the psymbols part.
It threw off me for a while, before I remembered that we only sort the
globals psymbols.