[Lldb-commits] [PATCH] Patch for LLDB demangler for demangling upon actual language
clayborg at gmail.com
Fri Jan 30 15:28:15 PST 2015
Not very important actually because our constant string pool (lldb_private::ConstString) has a:
ConstString::GetMangledCounterpart (ConstString &counterpart) const;
So we could just store the name and note if is is mangled or not and we would still have an accessor on symbol that we could change from:
GetMangled () const
/// Calculate and return a Mangled instance...
But again, this would help get lldb_private::Symbol to take less memory than it already does, but I still wouldn't want to lose those gains in savings by adding language with every mangled name. It doesn't really need to be there. And where it does and where it is important, we could add a language. It seems like a heavy hammer for a small controlled use case.
> On Jan 30, 2015, at 3:17 PM, Zachary Turner <zturner at google.com> wrote:
> Greg: How important is it from a performance perspective that Symbol be able to cache the demangled name and not recompute it every time you call GetDemangledName?
> rL LLVM
> EMAIL PREFERENCES
More information about the lldb-commits