Timeline

The multiplication sign in 'zit 34.1ms×2' never matched a byte compare, so the duration parsed as zero and the store note appeared beside an identical zit figure — claiming a wait already accounted for. check-in: 433a022052 user: quarry tags: trunk

A call on context.Background() carries no timer, so a page blocking six seconds on a warm pass reported 'ops 11.09s, zit 32.9ms' — and the ops panel's claim that ops minus zit is index work was false while it did. Overlap catches what attribution misses: subprocess busy time inside the render window, unioned, reported only when it exceeds what was already attributed. check-in: 17454ef71f user: quarry tags: trunk

branch.list grouped every check-in in the repository on every request: ~150ms in sqlite on tcl, 460-850ms through the driver, on a page whose budget is 500ms. A LIMIT could not help — the grouping happens before the limit applies. Same remedy as the ticket table: fold once when the shape changes, read by index. Refreshed in both fold paths, which the parity test insisted on. check-in: d6bf4e65b3 user: quarry tags: trunk

A subprocess on a render path is latency one reader pays for everybody, and one on a detached context is invisible in the footer while still counting toward the total — which is what sent the last investigation chasing SQL for an hour. check-in: 8c5b6e5392 user: quarry tags: trunk

Leaves expanded every twelve-character hash zit printed into a full one with a zit info call each: 473 leaves on sqlite meant 357 spawns and 6.1s in a single page-load window. The one consumer asks a membership question, which a twelve-hex-character key answers. Contract test now pins the prefix contract and that a full hash finds its leaf. check-in: 00e90b88cc user: quarry tags: trunk

zit leaves is 6.4s on sqlite, not the ~10ms this comment claimed, and the first reader paid it: 10.8s cold against 0.5s warm. Invisible in the footer too, since a detached context carries no timer. Warmed at registration and after each ingest; a reader arriving early gets no leaf marks rather than a six-second wait. check-in: e16d738900 user: quarry tags: trunk

col LIKE ? || '%' cannot use an index: the pattern is not a literal when the statement is prepared, so finding ONE check-in by its full hash read all 36,853 rows of sqlite's tree. That was 10s on a first timeline render and 40ms after, which reads as cold I/O and is not. Half-open hex ranges seek. Also sets cache_size, mmap_size and temp_store, none of which were configured. check-in: 22346a81a7 user: quarry tags: trunk

A ten-second page said 'ops 11.09s x8' and stopped there: the container is timed, its contents are not, so the slow one cannot be identified. Anything past 250ms now says which op it was. check-in: 3f926fafe8 user: quarry tags: trunk

The repository home fetched all 1,759 of sqlite's branches to draw a selector of twenty-five: 478ms of a 520ms page, spent building and marshalling rows nobody saw. branch.list gains limit and open, applied in SQL — the filter cannot follow the limit, or an old repository's first rows are all closed and the picker comes back empty. check-in: 1fc5dd6ba2 user: quarry tags: trunk

Chroma emits a span per token, so whole-file renders built DOMs nobody asked for: 198KB of build.c became 40,083 nodes and 137ms of parse. Lexing still starts at byte zero — a window opening inside a block comment cannot colour itself — but the iterator stops at the window's last line, so the tail is never tokenised. 103ms to 2.7ms for a first screen. Scroll fetches the next window; no-script gets a link. check-in: c517ec9464 user: quarry tags: trunk