amanusk / amanusk/snbeat

perf(registry): address/tx label lookups are linear scans, called several times per rendered row

Chiusa
#90 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
H performance snbeat
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

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.