This is the mail archive of the
mailing list for the GDB project.
RE: symbol table lookup performance
- To: <jtc at redback dot com>,<gdb at sourceware dot cygnus dot com>
- Subject: RE: symbol table lookup performance
- From: "Daniel Berlin" <dan at cgsoftware dot com>
- Date: Fri, 2 Jun 2000 20:39:18 -0400
> My users are again complaining about poor performance of user defined
> functions, and again I've tracked it down to GDB's poor symbol table
> lookup performance. I've got to finish my open projects before even
> thinking about tackling symbol table optimization, but I did a quick
> check to see if there was any low hanging fruit.
I'm looking at this myself.
> I profiled GDB, and determined that in running the script in question,
> some 67% of the time is spent in lookup_partial_symbol(), and that 27%
> of the time was spent in lookup_minimal_symbol().
> I discovered that most of the calls to lookup_minimal_symbol() were
> from fixup_section(), as it attempts to dig out section information
> from the minimal symbols. But in this case most of the symbols being
> "fixed up" were types (used in casts in the script) and therefore had
> no section. Thus fixup_section() would call lookup_minimal_symbol()
> again and again for the same type symbol.
> I hacked in a change to fixup_symbol_section() that avoids calling
> fixup_section() if sym->aclass == LOC_TYPEDEF. After that change, the
> number of calls to lookup_minimal_symbol drops from 13753 to 2866; and
> the time drops from 135 to 29 seconds.
> Of course my users want much, much more than a 20% speed increase, but
> it will have to do for now.
> Index: symtab.c
> RCS file: /usr/rback/release/tools-src/gdb_ce_fe/gdb/gdb/symtab.c,v
> retrieving revision 126.96.36.199
> diff -c -r188.8.131.52 symtab.c
> *** symtab.c 1999/07/15 18:46:07 184.108.40.206
> --- symtab.c 2000/06/02 21:54:43
> *** 558,563 ****
> --- 564,572 ----
> if (!sym)
> return NULL;
> + if (sym->aclass == LOC_TYPEDEF)
> + return sym;
> if (SYMBOL_BFD_SECTION (sym))
> return sym;
> Any thoughts on this change? It appears to work fine.
Looks fine to me.
Also, what type of debug info is this on?
It makes a huge difference.
If it's DWARF2, my "waiting for approval" changes i sent a few days ago will
reduce the total number of symbols dramatically, and thus, speed up the
symbol table stuff because it'll have to deal with less symbols.
If it's not too much trouble, could you tell me if lookup_partial_symbol is
trying to look up the same 100 or so symbols, again and again?
I would imagine at a given point in time, their is a set of symbols you'll
If it's trying to look up the same symbols, again and again, i'll implement
a simple LRU cache for the past 100 looked up symbols.