symbol table lookup performance

[jtc at redback dot com (J.T. Conklin)]

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 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 1.1.1.2
    diff -c -r1.1.1.2 symtab.c 
    *** symtab.c    1999/07/15 18:46:07     1.1.1.2 
    --- 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.  

        --jtc

-- 
J.T. Conklin
RedBack Networks