<div dir="ltr">I've have looked at paralelization of the module loading code some time ago, albeit with a slightly different use case in mind. I eventually abandoned it (at least temporarily) because I could not get it to work correctly for all use cases.<div><br></div><div>I do think that doing this is a good idea, but I think it will have to be done with a very steady hand. E.g., if I patch your changes in right now I get about 10 random tests failing on every test suite run, so it's clear that you are introducing a race somewhere.</div><div><br></div><div>We will also need to have a discussion about what kind of work can be done eagerly, as I believe we are trying to a lot of things very lazily (which unfortunately makes efficient paralelization more complicated).</div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2017 at 06:34, Scott Smith via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>The POSIX dynamic loader processes one module at a time.  If you have a lot of shared libraries, each with a lot of symbols, this creates unneeded serialization (despite the use of TaskRunners during symbol loading, there is still quite a bit of serialization when loading a library).<br><br></div>In order to parallelize this, I actually had to do two things.  Neither one makes any difference, only the combination improves performance (I left them as separate patches for clarity):<br><br></div>1. Change the POSIX dynamic loader to fork each module into its own thread.  I didn't use TaskRunner because some of the called functions use TaskRunner, and it isn't recursion safe.  The final modules are added to the list in the original order despite whatever order the threads finish.<br><br></div>2. Change Module::AppendImpl to fire off some expensive work as a separate thread.<br><br></div>These two changes bring startup time down from 36 (assuming the previously mentioned crc changes) seconds to 11.  It doesn't improve efficiency, it just increases parallelism.<br><br></div>
<br>______________________________<wbr>_________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@lists.llvm.org">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></blockquote></div><br></div>