worst case symbol lookup performance

J.T. Conklin jtc@redback.com
Tue Aug 10 12:04:00 GMT 1999

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
jtc> It appears that write_dollar_variable() calls lookup_symbol()
jtc> in order to expand HPUX/HPPA millicode functions ($$dyncall,
jtc> etc.).  In my run, write_dollar_variable() called
jtc> lookup_symbol() ~1000 times, which in turn called
jtc> lookup_partial_symbol ~2,000,000 times (we have ~20,000
jtc> symbols in our system).  But since the $ variables use in my
jtc> script will never be found in the symbol tables, I'm
jtc> encountering worst case behavior for each lookup.

Stan> Yow!  I'm pretty sure we shouldn't be looking for millicode
Stan> functions on anything besides HPUX native. :-) At the very
Stan> least, the bit of code should be conditionalized to not affect
Stan> anybody else.

If HPUX/HPPA is the only system with identifiers with leading $'s,
conditionalizing this code would be appropriate.  At the same time, 
I don't want to gloss over poor lookup performance in general.

jtc> I'm not familiar with the symbol handling portions of GDB, so I'm
jtc> looking for ideas.  Removing the symbol lookups from
jtc> write_dollar_- variable() significantly improves performance, but
jtc> doesn't solve the underlying problem.

Stan> Presumably you get a ~8 times speedup by removing the symbol
Stan> lookup.  What does profiling say is the most expensive operation
Stan> now?  

It still turns out to be lookup_partial_symbol at 85%+.  Of course,
it's 85% of a much smaller total.  In this case, the symbols are found
in the psymtab and are promoted to real symtab entries.


J.T. Conklin
RedBack Networks

More information about the Gdb mailing list