damacus
The TUI rebuilds every loaded document row on every draw, including when nothing changes. This wastes CPU and allocations as libraries grow. At 120x40 with 10,000 documents, the existing draw function measured 3.813 ms p95, 80,436 allocation/reallocation calls and 7,005,536 requested bytes per draw. At 100,000 documents it measured 40.420 ms p95. These are TestBackend render measurements, not key-to-screen latency. The event loop redraws before each 100 ms poll. ## Scope Use change-driven redraws, format the visible document range and avoid cloning inspector text when borrowing suffices. Handle resize, changed background results and selection correctly. Sources: src/tui.rs run_event_loop and draw. ## Passing bar - No unchanged idle redraws; less than 0.5% of one CPU core over 60 seconds idle. - At 10,000 documents: draw p95 <=1 ms and requested allocation bytes <=256 KiB per draw. - Tenfold growth in loaded rows causes less than twofold draw-time growth at fixed viewport size. - Real PTY key-to-frame p95 <50 ms; record its baseline first. - Preserve navigation, viewport offsets, scrollbars, resizing and background updates. ## Evidence and acceptance Baseline: commit ffd29e3, macOS arm64, release build, Rust 1.97.1, assessed 5 September 2026. These are local measurements, not production guarantees. Compare before/after with locked dependencies on the same machine in at least three interleaved batches. Keep timing checks out of shared-runner CI; test deterministic behaviour there. Preserve JSON, terminal output meaning and errors. Avoid new runtime dependencies. Reject unexplained CPU/RSS growth over 5% or executable growth over 1%.