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

[Dmitrii Galimzianov via lldb-commits]

DmT021 wrote:

> 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.

Yeah it sure would be a bottleneck. I didn't measure it precisely but I think I saw something about 30-50% of the time is spent on the mutexes in the string pools. And this is one of the reasons I gated the parallelized implementation behind the flag. One possible approach here would be to split the work done in the `ObjectFileMachO::ParseSymtab` into 3 phases: parsing, `ConstString` creation, and assigning the string to the symbols. So we can create all of the strings as one batch and minimize the locking penalty. `ParseSymtab` is a funny piece of code though and deserves its own pull request to address such things.

> 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.

Oh wow. 4.5 sec is amazingly fast. I'll try to reproduce your results.

> 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?

The machine is MBP M1 10 cores/32 GB. I'm testing this patch on [the swift fork](https://github.com/swiftlang/llvm-project/tree/stable/20230725) built in the `Release` mode and I'm attaching it to an iOS app(in the simulator) that has 978 modules. I'm running `lldb --local-lldbinit` in Instruments app with the following lldbinit file:
```
settings set plugin.dynamic-loader.darwin.enable-parallel-image-load 1
process attach --name browser_corp_ios
continue
```

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