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 <[email protected]> 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/
>
>
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
