This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: worst case symbol lookup performance
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: worst case symbol lookup performance
- From: jtc@redback.com (J.T. Conklin)
- Date: 10 Aug 1999 12:04:19 -0700
- Cc: gdb@sourceware.cygnus.com
- References: <199908101833.LAA21916@andros.cygnus.com>
- Reply-To: jtc@redback.com
>>>>> "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