<div dir="ltr"><div>As it turns out, it was lock contention in the memory allocator.  Using tcmalloc brought it from 8+ seconds down to 4.2.<br><br></div><div>I think this didn't show up in mutrace because glibc's malloc doesn't use pthread mutexes.<br><br></div><div>Greg, that joke about adding tcmalloc wholesale is looking less funny and more serious....  Or maybe it's enough to make it a cmake link option (use if present or use if requested).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 2, 2017 at 8:42 AM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="m_-5012448146526590794HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="m_-5012448146526590794HOEnZb"><div class="m_-5012448146526590794h5"><br>
> On May 2, 2017, at 8:09 AM, Scott Smith via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I've been trying to improve the parallelism of lldb but have run into an odd roadblock.  I have the code at the point where it creates 40 worker threads, and it stays that way because it has enough work to do.  However, running 'top -d 1' shows that for the time in question, cpu load never gets above 4-8 cpus (even though I have 40).<br>
><br>
> 1. I tried mutrace, which measures mutex contention (I had to call unsetenv("LD_PRELOAD") in main() so it wouldn't propagate to the process being tested).  It indicated some minor contention, but not enough to be the problem.  Regardless, I converted everything I could to lockfree structures (TaskPool and ConstString) and it didn't help.<br>
><br>
> 2. I tried strace, but I don't think strace can figure out how to trace lldb.  It says it waits on a single futex for 8 seconds, and then is done.<br>
><br>
> I'm about to try lttng to trace all syscalls, but I was wondering if anyone else had any ideas?  At one point I wondered if it was mmap kernel semaphore contention, but that shouldn't affect faulting individual pages, and I assume lldb doesn't call mmap all the time.<br>
><br>
> I'm getting a bit frustrated because lldb should be taking 1-2 seconds to start up (it has ~45s of user+system work to do), but instead is taking 8-10, and I've been stuck there for a while.<br>
><br>
</div></div><div class="m_-5012448146526590794HOEnZb"><div class="m_-5012448146526590794h5">> ______________________________<wbr>_________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
<br>
</div></div></blockquote></div><br></div></div>