[Debugger Visualizers] Optimize lookup behavior #147552
Open
+265
−227
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
Almost all of the commands in
lldb_commands
used a regex to associate a type with thesynthetic_lookup
andsummary_lookup
python functions. When looking up a type, LLDB iterates through the commands in reverse order (so that new commands can overwrite old ones), stopping when it finds a match. These lookups are cached, but it's a shallow cache (e.g. whenVec<T>
is matched by lldb, it will always point tosynthetic_lookup
, NOT the result ofsynthetic_lookup
which would beStdVecSyntheticProvider
).This becomes a problem because within
synthetic_lookup
andsummary_lookup
we runclassify_rust_type
which checks exact same regexes again. This causes 2 issues:.*
regex that associates withsynthetic_lookup
anywaysynthetic_lookup
and run its type through 19 regexes + some assorted checks every single time. Those checks take between 1 and 100 microseconds depending on the type.On a 10,000 element
Vec<i32>
(which bypassesclassify_struct
and therefore the 19 regexes), ~30 milliseconds are spent onclassify_rust_type
. For a 10,000 elementVec<UserDefinedStruct>
that jumps up to ~350 milliseconds.The salt on the wound is that some of those 19 regexes are useless (
BTreeMap
andBTreeSet
which don't even have synthetic/summary providers so it doesn't matter if we know what type it is), and then the results of that lookup function use string-comparisons in a giantif...elif...elif
chain.Solution
To fix all of that, the
lldb_commands
now point directly to their appropriate synthetic/summary when possible. In cases where there was extra logic, streamlined functions have been added that have much fewer types being passed in, thus only need to do one or two simple checks (e.g.classify_hashmap
andclassify_hashset
).Some of the
lldb_commands
regexes were also consolidated to reduce the total number of commands we pass to lldb (e.g.NonZero
An extra upshot is that
summary_lookup
could be completely removed due to being redundant.