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