[Lldb-commits] [lldb] DynamicLoaderDarwin load images in parallel (PR #110439)

Jason Molenda via lldb-commits lldb-commits at lists.llvm.org
Sun Oct 6 17:27:17 PDT 2024


jasonmolenda wrote:

This is an interesting idea, thanks for looking into it.  When I spoke with Augusto about it, my main concern was that all of the Modules would be trying to add strings to the constant string pool and lock contention could become a bottleneck.

I built github main unmodified, and with your parallel and parallel+preload patches and tried a quick benchmark.  I built with `-DCMAKE_BUILD_TYPE=Debug` and with `-DCMAKE_BUILD_TYPE=RelWithDebInfo` because unoptimized lldb can have very different perf behaviors.  I picked a random UI app -- Slack, a third party app using Electron, I have my system configured so I can attach to it -- and I used the command sequence like `time build.parallel-with-preload/bin/lldb -x -b -O 'settings set plugin.experimental.dynamic-loader.darwin.enable-parallel-image-load true' -o 'pro att -n Slack' -o 'det'` a few times for every configuration to get a rough idea of what perf looked like.

My Slack has 936 binaries loaded, typical for a UI app these days.  10 of the binaries are outside the shared cache (app frameworks/dylibs).  I did my tests on an M2 Max mac studio with 12 cores and 96GB of memory.

Built `RelWithDebInfo`, unmodified lldb took 4.5 seconds.  Parallel took 6.6 seconds.  Parallel with preload took 6.7 seconds.

Built `Debug`, unmodified lldb took 27.6 seconds.  Parallel took 35.5 seconds.  Parallel plus preload took 35.6 seconds.

One important thing I'm doing in this case is not creating a Target with a binary.  In `Target::SetExecutableModule` it calls `ObjectFileMachO::GetDependentModules` to get the list of all linked libraries, and loads the binaries at those filepaths into the target.  Then at process launch/attach time, if we'd already parsed the symbol table for a binary, it would be reused.

I'm curious what your machine/target process looks like, that we're seeing such different numbers.  I'm guessing you were testing an unoptimized build given the time amounts.  Does it look like I missed something with my test case?

https://github.com/llvm/llvm-project/pull/110439


More information about the lldb-commits mailing list