This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

worst case symbol lookup performance


Has anyone thought about the worst case performance of symbol lookup?

We have a library of user defined functions that grovel around data
structures and display information in a useful manner.  Due to poor
performance (for example, the function that displays a task listing
takes about a second per task on a PII 450), these functions are
hardly ever used --- our engineers to write throwaway code and bind
it into the executable.

But now that I've implemented crash dump support for our system, we
must use the user defined functions.  I built a profiled gdb with a
new CLI moncontrol command so I had better control over what I was
measuring, and determined that most (87%+) of the time was being spent
in lookup_partial_symbol.

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

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

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]