perf(registry): address/tx label lookups are linear scans, called several times per rendered row
- Lingua principale
- Rust
- Stelle
- 6
- Fork
- 1
- Merge medio
- 2h 16m
- PR unite (30g)
- 3
Descrizione
## Problem
`AddressRegistry::resolve`, `is_known`, `is_privacy_address`, `resolve_tx`, `get_decimals` and `format_address` (`src/registry/mod.rs`) each do a linear `Vec::iter().find()` over the user labels and then the bundled known addresses. Every rendered address row calls three to five of them (`known_or_palette_style` → `is_known` → `resolve`; `App::format_address` → `resolve`; `registry.format_address` → `resolve` again; plus `is_privacy_address` per inner target and `resolve_tx`).
With 759 user labels, a frame of the address Calls tab with 52k rows spent ~90 ms of its ~170 ms in these scans (measured with a `TestBackend` bench, release profile: 170 ms/frame with 759 labels vs 79 ms/frame with 0 labels).
Windowed rendering of the address tabs removes the per-frame multiplier, but the linear cost still hits:
- `update_tx_color_map` / `update_call_color_map` (`src/app/views/address_info.rs`), which iterate all rows × `is_known` whenever the list grows or a sender is enriched, i.e. on every WS event for a busy contract (~40M `Felt` compares at 52k rows).
- Block detail, tx detail and event tree rendering, which resolve labels per row/node.
- `known_addresses` search in `registry.search` is fine (already indexed); only the point lookups are affected.
## Proposed fix
Keep the `Vec`s for ordering but add O(1) indexes built once in `AddressRegistry::load`:
- `HashMap` for user labels, known addresses and tx labels.
- `HashSet` for `type = "Privacy"` known addresses.
Route all point lookups through the maps. `add_voyager_label` only touches `search_index`, so no runtime mutation of the new maps is needed.
## Severity
High: it scales with both list size and label count and sits on the UI thread inside `terminal.draw`.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Start in src/registry/mod.rs at AddressRegistry::load and the listed point-lookup methods, then review how the Vecs preserve ordering while new indexes are built. Route the user-label, known-address, privacy-address, and transaction lookups through the proposed maps and run the existing TestBackend release-profile benchmark; done means equivalent lookup behavior with point lookups no longer scanning the Vecs.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- rust
- Ambito
- performance
- Tipo di issue
- Refactoring
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Stato di attività
- Attiva
- Chiarezza
- Specificata chiaramente
- Idoneità per principianti
- 74/100