Viewer performance: the gallery was quadratic in the size of the whole store

[vicmaster]

Item 0 from the saved plan — the one slow thing you were already feeling daily. Measured first, because the three causes on that list were hypotheses and only one of them survived contact with a profiler.

What it measured, before

On the real store — 178 canvases across 15 projects, 3.9MB — the worst project page took 4.2 seconds cold and 2.2 seconds warm. Small projects were fine, which is why this only showed up as you accumulated repos.

The cause was not what I had written down

The saved note blamed the score cache thrashing against its 200-entry cap, live iframes, and per-repo aggregation cost. Two of those are wrong and the third is irrelevant at this size:

• Aggregation is 185ms cold and 65ms warm. Not the problem.
• The score cache is not thrashing: the store holds 178 canvases against a cap of 200, so nothing is being evicted.
• Scoring itself is cheap — about 8ms per canvas, and cached after the first render.

The actual cost was computing the cache key, at about 95ms per canvas. evalCacheKey needs to know which state variants a canvas has, so it calls designedStatesFor, which calls listCanvases() — and listCanvases() version-hashes every canvas in the store on every call. That happened once per card, and twice for any card whose score was not yet cached.

So a 43-canvas project sitting on a 178-canvas store performed roughly 7,600 whole-canvas hashes per page request. The page was quadratic in the size of the entire store rather than the project being viewed, which is exactly why it degraded as you registered more repos rather than as any single project grew. The cache was costing eleven times what it saved.

The fix

Take one listing per render and thread it through. designedStatesFor, evalCacheKey and evalFor now accept the states a caller already has, and renderProjectPage derives them from the listing it was already fetching for other reasons. Both single-argument forms still work unchanged, so the canvas detail page and the existing cache-key tests are untouched.

Same store, same pages, after:

Project	Before (cold / warm)	After
Largest (43 canvases)	4.23s / 2.18s	0.094s
Second	1.97s / 0.93s	0.090s
Third	1.03s / 0.55s	0.086s

What I deliberately did not touch

Aggregation and the score cache both measured clean, so changing either would have been motion without evidence. The 200-entry cap is worth revisiting only if the store grows past it — the honest trigger is a measurement, not a hunch, and this PR does not pre-empt it.

Live iframes are still one request per card. That is real browser-side work, but it is lazy-loaded and it was not what made the page slow; the static-thumbnail change belongs with the artboard-aware thumbnail work, where it also earns its keep for mobile canvases.

The regression test

test-viewer-perf.ts pins the shape rather than a wall-clock budget, so it means the same thing on a CI runner as on a laptop: quadrupling the store must not cost about sixteen times as much. The bound sits at eight, clear of honest variance and nowhere near quadratic.

It was verified against the pre-fix code rather than assumed to work — a regression test that would not have caught the bug is worth nothing. Reverting viewer.ts and running it gives 14.7x (45ms → 662ms); with the fix it gives 4.0x (3ms → 12ms).

It also covers the threading itself: a caller passing states it already has must produce the same key as a caller that looks them up, or the gallery and the detail page would key the same canvas differently and never share a cache entry.