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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
