[Lldb-commits] [lldb] [LLDB] Optimize identifier lookup in DIL (PR #146094)

Ilia Kuklin via lldb-commits lldb-commits at lists.llvm.org
Mon Jun 30 03:08:52 PDT 2025


kuilpd wrote:

> I'm not sure that's the right thing to do -- if there are multiple matches, how can we know we picked the one that the user wanted to see?
> What might matter for performance is, if returning false/nullptr here causes the implementation to perform the lookup at a larger (more expensive scope). If that's the case, then I'd say that the right thing is to _not_ do the second lookup in case the first one is ambiguous (as that doesn't help in resolving the ambiguity). So, the function could return one of three results: found zero, found one, found more than one; and in the last case we would immediately bail out.

Well, my logic was that it's better to return something than nothing, similar to what current `frame var` does, it just outputs the first thing that matches the base name, regardless of namespace. Should I make `DILFindVariable` return a specific error message like "ambiguous name" or something?

> That said, I think the search for the current CU has different performance characteristics (I believe it materializes all globals, and then searches for the right name), so while I'm not sure if it's necessary (this should be a one-shot thing), I can imagine implementing the search differently somehow, so that we can only return the "local globals" with the right name.

I tried doing `symbol_context.module_sp->GetSymbolFile()->FindGlobalVariables`, which in turn calls `SymbolFileDWARF::FindGlobalVariables`, but it searches through the entire module, not just current CU. `CompileUnit` class has only `GetVariableList`, no search. It looks like getting variable list there does something different, but I really can't tell if it's any faster.

https://github.com/llvm/llvm-project/pull/146094


More information about the lldb-commits mailing list