DmT021 wrote: > Why is it so expensive to perform consecutive lookups into the same module > for the same name? It depends on circumstances but basically, the worst-case scenario is when you: 1) lookup a symbol in the context of a huge module 2) the symbol is in another module 3) the huge module appears before the other module in the ModuleList
For example, I have a project that actively links its dependencies statically when possible, so the total number of symbols in the main executable is enormous(order of 10^6). When I perform a lookup for a foreign symbol (let's say `swift_retain`) in the context of this module I'll always search through this huge module twice. And this is probably quite common in practice. One will likely evaluate an expression while standing on a breakpoint in the main executable, and `swift_retain` will likely be looked up for any expression evaluation, and `libswiftCore` will appear after the main executable in the module list. > Should that be perhaps where we should focus the performance investigation > on? So users don't need to care about how many times we're doing the lookup? I was thinking about it and these two optimizations in particular: 1) Swift symbols contain module names. So we probably can infer a pretty good guess about the module from the symbol itself. 2) We probably can build an index of all the symbols in all the modules. But keeping this index in sync with the target's module list doesn't seem to be an easy task. Both of these approaches are of the scope of this change though. https://github.com/llvm/llvm-project/pull/102835 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
