[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