Re: new demangler

[mec.gnu@mindspring.com (Michael Elizabeth Chastain)]

Jim Blandy writes:
> When working on big C++ programs, I think I remember seeing that the
> mangled and demangled names take up a *lot* of memory.

I analyzed this recently.

  http://sources.redhat.com/ml/gdb/2003-12/msg00071.html
  http://sources.redhat.com/ml/gdb/2003-12/msg00092.html

One specific thinko caused a lot of trouble for monotone, which is built
with the boost libraries.  But mozilla does not have any symbols which
were affected by this bug, so memory size on mozilla probably didn't get
any better with this bug fix.

The new demangler has the same memory requirement has old demangler +
bug fix (46 megabytes on monotone).  But the new demangler runs a lot
faster.  Check out the difference in elapsed time between "H21" and
"H30" in my table.  gdb with old demangler + bug fix starts up in 9.46
seconds, and gdb with new demangler starts up in 3.03 seconds.

> If that recollection is correct, it might be cool to have GDB store
> the trees instead of the names, and throw a bcache at the nodes in
> these demangled name trees, working from the leaves upward, to get
> maximum sharing.  I bet that would bring the memory requirements down
> to something more closely resembling the actual number of classes,
> methods, etc. in the program.

How about quantifying gdb performance (space and time) on a real
program first.  There might not be a problem at all.  Then look for some
low-hanging fruit before pulling out the algorithmic guns.

Michael C