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

[Scott Smith via llvm-dev]

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>
>> wrote:
>> >
>> > 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,
>> right?
>>
>
> This seems correct. libcxxabi demangler [1] is different from the one used
> by llvm [2]. 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 [2] (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.
>
> [1] https://github.com/llvm-mirror/libcxxabi/blob/master/src/
> cxa_demangle.cpp
> [2] https://github.com/llvm-mirror/llvm/blob/master/lib/
> Demangle/ItaniumDemangle.cpp
> [3] https://github.com/llvm-mirror/libcxx/blob/master/include/__
> threading_support
>
> PS: Here's a particularly amusing bug of the current libcxxabi demangler:
> https://bugs.llvm.org//show_bug.cgi?id=31031
>
> Cheers,
>
> / Asiri
>
>
>>
>> vedant
>>
>>
>> > 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
>> >
>> >
>>
>> _______________________________________________
>> 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/94e10ae5/attachment.html>