Re: PATCH RFC: Patches to speed up the demangler

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Dec 28, 2003 at 10:56:43AM -0800, Mark Mitchell wrote:
> On Sat, 2003-12-20 at 12:16, Ian Lance Taylor wrote:
> > I spent some time investigating how to speed up the new demangler,
> > because it turns out to affect gdb startup time on C++ executables.
> 
> I don't have anything bad to say about your patch, but I do think that
> the behavior you mention here is a bug in GDB.  I noticed that ages ago,
> but have never done anything about it.  GDB should lazily demangle
> names; that would be much more scalable.  In fact, I would keep an LRU
> cache of a few thousand such names; in a very big program, the memory
> required to demangle all of the names may well be prohibitive.

The issue seems to be a little more complex than that.  Given "break
foo", we need to find all the methods whose base name is foo - the most
apparent way to handle the existing symbol table does not lend itself
to a query of that sort without either demangling, or substantial hacks
for each supported mangling, to guarantee that _Z3foo1a and _Z3foo1b
hash to nearby locations.  We can't rely completely on the debug
information; what if foo is in a shared library with no debugging
information, such as libstdc++?

Now, if you have any ideas on how to approach this problem, I'd love to
hear them.  Also even given that constraint GDB's startup is somewhat
suboptimal - please don't think I'm claiming otherwise :)  The biggest
improvement I'm currently planning is .debug_info_index, currently a
proposal to the DWARF working group.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer