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