[Lldb-commits] [PATCH] D32598: Prime module caches outside of the module list lock for better parallelism

[Scott Smith via Phabricator via lldb-commits]

scott.smith added a comment.

In https://reviews.llvm.org/D32598#739779, @clayborg wrote:

> Making an empty main program and saying I see no difference is not enough testing to enable this.


It's not quite an empty main program; it links in 40+ shared libraries with 2M+ symbols.  The point of having main() just return 0 is so I could compare the performance of "b main; run" vs "run" without taking program execution into account, but just the amount of work lldb does.

But as it turns out, I still managed to screw that up.  I'm now seeing a difference:

WITHOUT CHANGE:
lldb -b -o 'b main' -o 'run' xyz:
real 0m15.248s
user 0m24.632s
sys 0m3.839s
lldb -b -o 'run' xyz:
real	0m11.540s
user	0m9.692s
sys	0m0.892s

WITH CHANGE:
real 0m9.747s
user 0m29.507s
sys 0m10.531s

(timings are reasonably representative, but they do change a bit run to run)

> I also don't see the benefit of this path.

It improves lldb startup time significantly.  Our use cases seem centered around using symbols, so for us, delaying loading of symbols does not help, it just moves when we wait to another point.

> When LLDB is used for symbolication, it might never actually load any debug info or symbols from modules that are added to a target. Also if there is any DWARF that doesn't have the Apple accelerator tables then the DWARF manually indexes itself by spawning threads that will index a compile unit per thread using a thread pool.. So now if we load all symbols at once, using NUM_CORES threads, and then each DWARF file spins off NUM_CORES threads to index the DWARF we can probably bring the machine to the brink?

No, because it uses a global TaskPool, so regardless of how many users there are, there will only be NUM_CORES threads.  Note my comments in https://reviews.llvm.org/D32597 about changing TaskPool so it will be file-local instead of global, so TaskPool workers can spawn other TaskPool work.


Repository:
  rL LLVM

https://reviews.llvm.org/D32598