JDevlieghere added a comment. In D131328#3704791 <https://reviews.llvm.org/D131328#3704791>, @jasonmolenda wrote:
> Interesting idea, it seems worth trying out and seeing how it works in > practice. > > My read of the llvm::ThreadPool is that this won't create an unbounded number > of threads doing background fetches, right. Some of the big UI apps in macOS > these days can have a thousand dylib/frameworks loaded in them. Correct, the thread pool is limited by the number of cores/physical CPUs (depending on the ThreadPoolStrategy). I contemplated using a dedicated thread pool for this, but didn't like the idea of having to manage its lifetime and pick and arbitrary fixed number. The only risk here is that we starve other work scheduled on this ThreadPool (currently that's building the manual DWARF index, so not really a concern on our platform). In D131328#3705187 <https://reviews.llvm.org/D131328#3705187>, @jasonmolenda wrote: > I wonder if it might be interesting to target this a bit - only start > background downloading the dSYM for a Module once it has appeared in a > backtrace, for instance. Any UI application on macOS etc has around 500 > libraries loaded, but I believe only a few dozen of those libraries will > actually appear in backtraces as they're debugging. We could delay it until > the UnwindTable ctor is called for instance -- that's the first thing that > will happen when a Module is in a backtrace. Just thinking aloud, not > arguing for it especially. I really like this suggestion. It did bother me how naive/wasteful the current approach is. The downside of doing this more lazily is that you potentially had enough time to fetch everything by the time you did the first backtrace. But it's equally likely that you're waiting for those one or two modules you did care about (and are part of the backtrace) while 200 others you don't care about are being pulled in. I think your suggestion hits the sweet spot in terms of latency and doing only meaningful work. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131328/new/ https://reviews.llvm.org/D131328 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
