[Lldb-commits] [PATCH] Patch for LLDB demangler for demangling upon actual language

[Greg Clayton]

Not very important actually because our constant string pool (lldb_private::ConstString) has a:

    bool
    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:

    Mangled&
    GetMangled ()
    {
        return m_mangled;
    }

    const Mangled&
    GetMangled () const
    {
        return m_mangled;
    }


to be:


    Mangled
    GetMangled ()
    {
	Mangled mangled;
        /// Calculate and return a Mangled instance...
	...
	return mangled;
    }

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.

Greg


> 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?
> 
> 
> REPOSITORY
>  rL LLVM
> 
> http://reviews.llvm.org/D7302
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
>