On Tue, May 2, 2017 at 12:43 PM, Greg Clayton wrote:
> The other thing would be to try and move the demangler to use a custom
> allocator everywhere. Not sure what demangler you are using when you are
> doing these tests, but we can either use the native system one from
> the #include , or the fa
The other thing would be to try and move the demangler to use a custom
allocator everywhere. Not sure what demangler you are using when you are doing
these tests, but we can either use the native system one from the #include
, or the fast demangler in FastDemangle.cpp. If it is the latter,
then
As it turns out, it was lock contention in the memory allocator. Using
tcmalloc brought it from 8+ seconds down to 4.2.
I think this didn't show up in mutrace because glibc's malloc doesn't use
pthread mutexes.
Greg, that joke about adding tcmalloc wholesale is looking less funny and
more seriou
I'm not sure about Linux, on OS X lldb will mmap the debug information rather
that using straight reads. But that should just be once per loaded module.
Jim
> On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev
> wrote:
>
> I've been trying to improve the parallelism of lldb but have run in
If you have access to a Windows machine and you can reproduce the slowdown
there, there are surprisingly good tools available for diagnosing
parallelism and thread contention.
https://github.com/google/UIforETW
On Tue, May 2, 2017 at 8:09 AM Scott Smith via lldb-dev <
lldb-dev@lists.llvm.org> wro
