Parents and children of check-in [d6bf4e65b3]
|
2026-08-31
| ||
| 15:37 |
the footer names store wait the timing context missed
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 | |
| 15:24 |
fold the branch summary instead of deriving it per request
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 | |
| 15:17 |
warm the default branch too, so ops minus zit means what it says
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 | |