llvm dev - Apr 2017 - RFC: Improving the performance of ItaniumDemangle

(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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/171063dd/attachment.html>

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

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>