diff options
| author | blasty <blasty@local> | 2026-08-10 00:14:51 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-08-10 00:14:51 +0200 |
| commit | ccf4616a0ace008af427234358ee256e537bfa02 (patch) | |
| tree | 7e850556cd97005bb21fdc89a208d8c905cf60f8 /docs/PROJECTS.md | |
| parent | remote_tools: delete a shadowed duplicate hiding an lru_cache landmine (diff) | |
| download | ida-tui-ccf4616a0ace008af427234358ee256e537bfa02.tar.gz ida-tui-ccf4616a0ace008af427234358ee256e537bfa02.tar.xz ida-tui-ccf4616a0ace008af427234358ee256e537bfa02.zip | |
Skeleton pages: stop rendering 227k rows to count them (3x boot)
ListingView._grow streams the entire segment in the background for one
reason: to learn how many rows it has, so the scrollbar and paging are
right. It did that by rendering every row in full -- 227,500 rows of a
1.2MB bash, 911 backend calls, 9.3 seconds -- essentially none of which is
ever looked at.
generate_disasm_line is 22x the cost of the walk around it, so heads() gains
text=False: a SKELETON page with the same rows at the same addresses with the
same kinds and sizes, and no rendered text. Measured identical structurally
(rows, addresses, kinds, sizes and cursor all match a real page) which is
what makes one swappable for the other later. It also skips the digest
(nothing to go stale) and lets the client skip the bulk opcode read, so a
page costs ONE round trip instead of two.
Client side is deliberately tiny, because the machinery already existed: a
skeleton page is just a page whose text is stale. It is marked with a
sentinel generation no _text_gen can equal, and the FIRST read of it goes
through the same _ensure_text/_ensure_page path a rename uses -- which
already refetches a page by address, verifies the structure still lines up
and splices it in. Two staleness gates learn to fire for _skeleton as well
as _renamed; that is the whole integration.
bash boot: 911 calls / 9.26s -> 456 calls / 3.12s, 3.0x. The trade is that a
page you actually display is fetched twice (3.3ms + 9.4ms vs 9.4ms), paid
only for what is shown. _prime still loads real pages, so the viewport you
land on is never a skeleton.
The failure mode is BLANK ROWS, not an exception, and nothing in the suite
scrolled far enough to see one: _prime renders the first ~1000 rows for real,
so a test that pages down a few screens passes against a completely broken
implementation. The new scenario reads deep rows through both the model and
the render path, and asserts materialising changes neither the row count nor
the walk. Verified by reverting the two gates: it fails with text=''.
Full gate: 1050 passed.
Diffstat (limited to 'docs/PROJECTS.md')
0 files changed, 0 insertions, 0 deletions
