[llvm-dev] RFC: Improving the performance of ItaniumDemangle
Scott Smith via llvm-dev
llvm-dev at lists.llvm.org
Tue Apr 25 14:09:01 PDT 2017
The libcxxapi demangler doesn't look any faster than the llvm demangler.
It still suffers from excessive use of malloc.
On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake <
asiri.rathnayake at gmail.com> wrote:
> On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com>
>> > well, top-of-branch lldb uses this code, that's how I found it. Do you
>> mean libc++'s demangler?
>> Thanks for explaining, this is the first time I'm looking at the
>> demangler situation. It looks like libcxxabi has an arena-based demangler,
>> and that the one in llvm is different.
>> I'm confused by this because the comment in llvm says that libcxxabi is
>> supposed to reuse the llvm demangler. This doesn't seem to be happening,
> This seems correct. libcxxabi demangler  is different from the one used
> by llvm . I'm hoping Saleem, Eric or Jon (copied) knows a bit of history
> as to why this is so (perhaps because the two projects evolved
> independently ?).
>> > 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)
>> Do you know what the llvm policy is on using TLS in library code? I can't
>> find any mention of this in the programmer's manual, and my officemates
>> don't know either.
> Both libcxx and libcxxabi use __libcpp_tls_*() functions of the threading
> API  (which call pthread functions on most platforms) for thread-local
> storage needs. IIRC thread_local is not implemented across all the
> platforms that llvm support.
> If the idea is to improve libcxxabi's demangler, then it should be
> straightforward to use these functions instead of thread_local.
>  https://github.com/llvm-mirror/libcxxabi/blob/master/src/
>  https://github.com/llvm-mirror/llvm/blob/master/lib/
>  https://github.com/llvm-mirror/libcxx/blob/master/include/__
> PS: Here's a particularly amusing bug of the current libcxxabi demangler:
> / Asiri
>> > 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
>> > 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
>> > >
>> > > _______________________________________________
>> > > LLVM Developers mailing list
>> > > llvm-dev at lists.llvm.org
>> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev