worst case symbol lookup performance

Guenther Grau Guenther.Grau@bosch.com
Thu Aug 12 03:40:00 GMT 1999


Jim Blandy wrote:
> Hah.  At the GDB meeting I just gave a presentation about GDB's symbol
> table structures, in which everyone was astonished at the lack of hash
> tables or trees or anything reasonable, to which I happily replied
> that lookups were fast enough without them.  Well, I guess that didn't
> last long.

Oh, well I guess then you are just missing some user feedback :-)
This is of course, our (the users) fault, not yours.

> How many object files do you have?  That is, how many entries are

Hmm, almost too many to count them... Our binaries are about 150 MB
in size on the harddisk. This is on Solaris. On HP-UX they are a little
smaller, about 70 to 80 MB. It takes quite a while to look up some
symbols, no real data from measurements, though. But it's still usable.
What really becomes a problem is trying to get a stacktrace from 
a core dump under HP-UX. Reading a core file of 30 MB (from a smaller 
process :-) grows gdb to about 250 MB in RAM. (Besides, that it still
often gets the stack wrong :-( But I guess this is an HP problem.
Their old debugger xdb shows even less of the stack and busy-loops
forever while doing a bt. Oh, I don't know if this matters, but
this is mostly C++ code.


More information about the Gdb mailing list