[Debugger Visualizers] Optimize lookup behavior #147552
Open
+281
−233
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
S-waiting-on-review
Collaborator
|
rustbot has assigned @Mark-Simulacrum. Use |
Member
|
While I'm not comfortable reviewing this myself (and it might be tricky to find someone who is), I do want to at least say thanks for working on it. |
Contributor
Author
|
If it helps the review any, this is more or less how it should have been written from the start. The The MSVC providers I added a while ago already point directly to the initializer rather than taking a trip through There shouldn't be any actual changes for end-users (aside from |
Member
|
r=me if this is still ready to go (not sure if other changes have landed in the last month that make a rebase make sense). I think we can land this and revert/revisit if it runs into issues, the description makes sense to me and the changes seem reasonable. |
jieyouxu
approved these changes
Nov 12, 2025
Member
|
@bors r=Mark-Simulacrum,jieyouxu rollup |
Collaborator
bors
added
S-waiting-on-bors
Member
|
Uh actually @Walnut356, this doesn't need a rebase or anything, right? If not, please r= us |
bors
added
S-waiting-on-author
Collaborator
|
✌️ @Walnut356, you can now approve this pull request! If @jieyouxu told you to " |
Contributor
Author
Collaborator
bors
added
S-waiting-on-bors
Member
|
@bors r=Mark-Simulacrum,jieyouxu |
Collaborator
|
💡 This pull request was already approved, no need to approve it again. |
Collaborator
Collaborator
bors
added a commit
that referenced
this pull request
Nov 15, 2025
[Debugger Visualizers] Optimize lookup behavior # Background Almost all of the commands in `lldb_commands` used a regex to associate a type with the `synthetic_lookup` and `summary_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. when `Vec<T>` is matched by lldb, it will always point to `synthetic_lookup`, NOT the result of `synthetic_lookup` which would be `StdVecSyntheticProvider`). This becomes a problem because within `synthetic_lookup` and `summary_lookup` we run `classify_rust_type` which checks exact same regexes again. This causes 2 issues: 1. running the regexes via lldb commands is even more of a waste because the final check is a `.*` regex that associates with `synthetic_lookup` anyway 2. Every time lldb wants to display a value, that value must run the entirety of `synthetic_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 bypasses `classify_struct` and therefore the 19 regexes), ~30 milliseconds are spent on `classify_rust_type`. For a 10,000 element `Vec<UserDefinedStruct>` that jumps up to ~350 milliseconds. The salt on the wound is that some of those 19 regexes are useless (`BTreeMap` and `BTreeSet` 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 giant `if...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` and `classify_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.
This comment has been minimized.
This comment has been minimized.
Collaborator
|
💔 Test failed - checks-actions |
bors
removed
the
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
Mark-Simulacrum
added
S-waiting-on-author
Collaborator
|
☔ The latest upstream changes (presumably #89917) made this pull request unmergeable. Please resolve the merge conflicts. |
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Contributor
Author
|
@rustbot review |
rustbot
added
S-waiting-on-review
Member
|
@bors r+ |
Collaborator
bors
added
S-waiting-on-bors
Kivooeo
added a commit
to Kivooeo/rust
that referenced
this pull request
Dec 20, 2025
[Debugger Visualizers] Optimize lookup behavior # Background Almost all of the commands in `lldb_commands` used a regex to associate a type with the `synthetic_lookup` and `summary_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. when `Vec<T>` is matched by lldb, it will always point to `synthetic_lookup`, NOT the result of `synthetic_lookup` which would be `StdVecSyntheticProvider`). This becomes a problem because within `synthetic_lookup` and `summary_lookup` we run `classify_rust_type` which checks exact same regexes again. This causes 2 issues: 1. running the regexes via lldb commands is even more of a waste because the final check is a `.*` regex that associates with `synthetic_lookup` anyway 2. Every time lldb wants to display a value, that value must run the entirety of `synthetic_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 bypasses `classify_struct` and therefore the 19 regexes), ~30 milliseconds are spent on `classify_rust_type`. For a 10,000 element `Vec<UserDefinedStruct>` that jumps up to ~350 milliseconds. The salt on the wound is that some of those 19 regexes are useless (`BTreeMap` and `BTreeSet` 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 giant `if...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` and `classify_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.
bors
added a commit
that referenced
this pull request
Dec 20, 2025
Rollup of 7 pull requests Successful merges: - #147552 ([Debugger Visualizers] Optimize lookup behavior) - #149437 (Fix trailing newline in JUnit formatter) - #149812 (Add const default for OnceCell and OnceLock) - #150035 (fix docustring on fetch_or) - #150160 (Fix ICE (#149980) for invalid EII in statement position) - #150191 (change non-canonical clone impl to {*self}, fix some doc comments) - #150203 (Drop the From derive macro from the v1 prelude) r? `@ghost` `@rustbot` modify labels: rollup
Member
|
Unknown argument "aarch64-apple". Run |
bors
added
S-waiting-on-author
Member
|
@bors try jobs=aarch64-apple |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Dec 20, 2025
[Debugger Visualizers] Optimize lookup behavior try-job: aarch64-apple
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test for a74aee3 failed: CI. Failed jobs:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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_commandsused a regex to associate a type with thesynthetic_lookupandsummary_lookuppython 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_lookupwhich would beStdVecSyntheticProvider).This becomes a problem because within
synthetic_lookupandsummary_lookupwe runclassify_rust_typewhich checks exact same regexes again. This causes 2 issues:.*regex that associates withsynthetic_lookupanywaysynthetic_lookupand 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_structand 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 (
BTreeMapandBTreeSetwhich 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...elifchain.Solution
To fix all of that, the
lldb_commandsnow 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_hashmapandclassify_hashset).Some of the
lldb_commandsregexes were also consolidated to reduce the total number of commands we pass to lldb (e.g.NonZeroAn extra upshot is that
summary_lookupcould be completely removed due to being redundant.