This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFC: Patches to speed up the demangler

On Sun, 2003-12-28 at 11:47, Daniel Jacobowitz wrote:
> 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 

That's a good point.  

You could still defer demangling until the point where someone did
"break foo" or something similar.  Every currently supported mangling
encodes a basename as "foo" as "3foo"; it's the stuff around that where
there's a difference.  So, you could look for "3foo" in the mangled
names and demangle only those.  That scheme would have you progressively
demangling more and more things as the user used the debugger; you would
more trade linear scans over all the demangled names for fewer calls to
the demangler.  

You'd have to measure to see how well that worked.

Mark Mitchell <>
CodeSourcery, LLC

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