diff options
| author | blasty <blasty@local> | 2026-07-25 14:41:17 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-07-25 14:41:17 +0200 |
| commit | 23ee522a8b4fed9de62cd3bdfac8656c606a9d3c (patch) | |
| tree | 23425f47abc51902afae52c47080bb0296013ef0 /tests/test_project_ui.py | |
| parent | projects: project-wide symbol search over a SQLite FTS5 index (phase 2) (diff) | |
| download | ida-tui-23ee522a8b4fed9de62cd3bdfac8656c606a9d3c.tar.gz ida-tui-23ee522a8b4fed9de62cd3bdfac8656c606a9d3c.tar.xz ida-tui-23ee522a8b4fed9de62cd3bdfac8656c606a9d3c.zip | |
palette: cut the per-keystroke cost of project-wide symbol search
Reported as sluggish up/down navigation in project scope. Measuring it turned up
two things:
* The arrow keys themselves aren't the problem, and it isn't list length: a
synthetic down-key benchmark reads a flat ~62 ms/key from 20 to 400 options in
BOTH scopes. That is a fixed floor in pilot.press() (Textual awaits a full
refresh cycle per synthetic press), so the harness can't isolate real key
latency — the number says nothing about the app.
* What IS measurably worse in project scope is the work done per typed
character: 29.5 ms vs 17.8 ms locally.
Fix the part that's real. The trigram index already guarantees every hit contains
the query, so ranking only has to ORDER them — an exact-substring rank (match
position, then name length) costs one find() per row instead of a full fuzzy pass,
and fetching 3x the display limit instead of 10x cuts the candidate set. As a
bonus the highlight spans come straight from the match position.
Per-keystroke _apply over a 30k-entry, 6-binary index, typing "m"->"main_":
before project ~29.5 ms
after project 10.8 / 11.2 / 11.9 / 13.2 / 14.2 ms
(local, unchanged, for reference: 13.8 / 14.3 / 15.2 / 16.2 / 38.8 ms)
Project scope is now cheaper per keystroke than local scope, whose fuzzy pass
over every function is the remaining hot spot. Suite 191/0.
Diffstat (limited to 'tests/test_project_ui.py')
0 files changed, 0 insertions, 0 deletions
