[llvm-dev] RFC: Improving the performance of ItaniumDemangle

[Scott Smith via llvm-dev]

well, top-of-branch lldb uses this code, that's how I found it.  Do you
mean libc++'s demangler?

FYI when I said 14+% (and now it's 17%), I mean the overall performance of
starting lldb, not just the demangler itself.  It's probably several times
faster now with this change (https://reviews.llvm.org/D32500)


On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wrote:

> I thought the plan of record was (r280732):
>
> '''
> Once the fast demangler in lldb can handle any names this
> implementation can be replaced with it and we will have the one true
> demangler.
> '''
>
> What is the status of lldb's fast demangler? Is it available on Ubuntu
> 16.04?
>
> vedant
>
>
> > On Apr 24, 2017, at 6:02 PM, Scott Smith via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > (Again), while trying to improve the performance of lldb, I ran into a
> bottleneck with the demangler.  This may be specific to my platform -
> Ubuntu 16.04, probably using libstdc++, not libc++.  It makes extensive use
> of std::string and std::vector, and I see memory allocation at the top.  I
> prototyped a version that uses an arena-style memory allocator (you can
> allocate, but you can't ever free).  It is approximately 14+% faster.  I
> think I can further optimize it by making repeated appends zero-copy (for
> the string being appended too).
> >
> > The code right now is a little ugly, because it uses a thread local
> variable to pass around the arena pointer, rather than change every + and
> += to be function calls that take db.arena as a parameter.  I'm not sure
> what you guys would prefer for that either (thread local variable vs api
> change).
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170425/b96fc1d2/attachment.html>