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

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

Thanks for all the work you've done on this, and updating the setting.  I looked over the implementations, and they all look like reasonable changes to me - I did laugh a little when I realized that 2/3rds of all the changes were related to adding the setting :) that's always a bit of boilerplate for the first setting in a plugin.

In a process launch scenario, or attaching to a process when it was launched in a stopped state, there will only be two binaries, dyld and the main app binary, and I don't think there would be any much perf benefit to the "preload" approach where we can parallelize special binaries (dyld, main executable) -- dyld is just a little guy.  But when we attach to a launched app, where we have the two special binaries and a thousand others, if we load those two special binaries sequentially, all the other binaries are blocked until a possibly-expensive main binary has been parsed, and I think that's where the real perf difference you were measuring kicked in (you showed a 10.5 second versus 13.4 second time difference for preload versus parallel in the beginning), do I have that right?  Or were you attaching to a stopped process with just dyld+main binary, I can't imagine doing those two in parallel would lead to the savings you measured.

I think the preload approach where we can parallelize the two special binaries along with all the others on a "fully launched process" attach scenario is the right choice, thanks for investigating both of them and presenting both options.  Do you prefer the non-preload approach?  I know it is a simpler patch, but I can see how the perf benefit of preload could be significant with attaching to a fully launched process.

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