worst case symbol lookup performance

[J.T. Conklin]

>>>>> "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.

        --jtc

-- 
J.T. Conklin
RedBack Networks