Re: Bcache'ing as a speedup

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> If we bcache every symbol/psymbol/minsym name, and i mean literally
> every single one, couldn't we just do simple pointer compares (IE
> a==b) rather than strcmp (assuming we weren't doing a strcmp_Iw, which
> obviously would still need to be done), since if they were the same
> string, they would *have* to be pointing to the same memory?
> 
> Wouldn't this be a pretty large speed win?

Have you actually observed that GDB spends a lot of time in strcmp, or
is that just a guess?  You could be right, but guesses of that species
are notoriously poor bets.

Also: whenever you notice that a program spends a lot of time doing
procedure X, there are two approaches (not necessarily mutually
exclusive): you can make procedure X faster, or you can reduce the
number of times procedure X is needed.

For example, speeding up the minsym lookups with hash tables was a
localized change that was very effective.  Rather than speeding up
strcmp, Tom introduced a better data structure, so that we only called
strcmp a tiny fraction as often as we used to.

The change you suggest has some pretty global consequences; for
example:
- symbol names can no longer be freed with their objfile
- everyone must always remember to bcache their names before looking
  them up / storing them, or else lookups will mysteriously fail

I think there are bigger wins elsewhere, without these side effects.

Srikanth at HP has spent some time observing where GDB spends its time
in real-life situations, and has implemented some speedups in HP's
version of GDB that look attractive to me.  For example, Srikanth
found that GDB could spend 40% of its symbol reading time trying to
demangle symbols, so he worked out some changes to GDB's minsym
structures that allow GDB to demangle C++ symbol names selectively, as
needed, rather than all at once when the symbol table is read.  HP and
I have been talking about getting this change merged; we'll probably
be describing it on this list sometime soon.