Skip to content

Conversation

Walnut356
Copy link
Contributor

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.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 10, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 10, 2025

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@Zalathar
Copy link
Contributor

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.

@jieyouxu jieyouxu self-assigned this Oct 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants