Michael137 wrote: I attached to clang and printed an expression. That resulted in 16801 calls to `Progress::Increment`, all of which I'm guessing translate to event broadcasts. I collected some timing numbers: ``` <img width="205" alt="image" src="https://github.com/llvm/llvm-project/assets/14071464/97333f8a-2e35-47c9-8cd0-d610daa077fd";> ```
So across the various scenarios i tested the slowdown is somewhere between 10-90 ms on average. > I'd expect that a one of these operations (parsing/importing one type) would > be pretty fast, and that the whole process takes so long simply because > performing a very large number of these ops. @labath Mostly that's true. Occasionally these operations can take longer if we end up searching for types/functions across multiple object files (especially with https://github.com/apple/llvm-project/pull/8222). We could certainly consider some sort of rate limiting here. Or maybe find a better place to report progress on? > Anyway, if the code is recursive, we might need to do something like we did > for Swift, with one top-level event and callback that updates the details. @JDevlieghere @adrian-prantl are there plans to change the presentation layer to prevent this kind of shadowing in the future? Would be nice if all we needed to do was report progress, and not worry about other progress events in the debugger being in-flight https://github.com/llvm/llvm-project/pull/91452 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
