aboutsummaryrefslogtreecommitdiffstats
path: root/experiments/cfg_dump.py
diff options
context:
space:
mode:
authorblasty <blasty@local>2026-08-10 00:14:51 +0200
committerblasty <blasty@local>2026-08-10 00:14:51 +0200
commitccf4616a0ace008af427234358ee256e537bfa02 (patch)
tree7e850556cd97005bb21fdc89a208d8c905cf60f8 /experiments/cfg_dump.py
parentremote_tools: delete a shadowed duplicate hiding an lru_cache landmine (diff)
downloadida-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 'experiments/cfg_dump.py')
0 files changed, 0 insertions, 0 deletions