/:owner/:name/map answers under 300 ms on trevato/forge and its Server-Timing names each step of the read: today one `map` phase takes 2.5–3.6 s #8401

The map page's read now reports each step as its own Server-Timing phase. I did not reproduce the 2.5–3.6 s on a graph the size of trevato/forge, so I can't say I found the slow step.

On the test fixture (3,300 issues of which 300 open, 600 edges, 10 pillars) the whole read takes about 75–100 ms warm, with or without my src/core/dependencies.ts changes. My guess is that production's real graph shape is what triggers the slow case, but I haven't confirmed it.

What changed

• Server-Timing: src/web/pages/map.ts emits map-graph, map-ready, map-blocked, map-critical, map-layout, map-marks, map-pillars and map-ask. The map total stays as before.
• Reach walks shared: readyNow, idleFurniture and blockedOn each rebuilt the same "holds up" and "waits for" maps for one graph. They are now built once per graph, held in a WeakMap.
• Quadratic copies removed: two places in src/core/dependencies.ts copied the whole waiter list for every edge. They now append to it.
• Same answers: the page, the API and the MCP map return the same results as before. The existing map and dependency tests pass unchanged.

Before and after, warm, on the fixture

• map-ready: before the change it was 31 ms on the first read and 6 ms on the second. After it was 6 ms.
• map-graph and map-marks: the largest steps, at about 35 ms and 22 ms. I did not change them.

Test: test/map-speed.test.ts builds that fixture, checks that all eight phases are present, and asserts map is under 300 ms.

How to try it: open /trevato/forge/map on the preview and read the Server-Timing header. If the production map is still slow after this, the eight phases will show which step it is.

Not done: I did not find or fix a step that takes seconds, because none did on the fixture. I ran the tests that cover map.ts and dependencies.ts, mcp-size.test.ts, the gate, tsc and the design lint, and all passed. I did not run the full suite (the forge's check does). scripts/fast.ts reported the diff reaches 1,330 of 1,872 test files, so I picked the covering tests myself.

Closes #8381

The map page's read now reports each step as its own Server-Timing phase. I did not reproduce the 2.5–3.6 s on a graph the size of trevato/forge, so I can't say I found the slow step.

On the test fixture (3,300 issues of which 300 open, 600 edges, 10 pillars) the whole read takes about 75–100 ms warm, with or without my src/core/dependencies.ts changes. My guess is that production's real graph shape is what triggers the slow case, but I haven't confirmed it.

What changed

• Server-Timing: src/web/pages/map.ts emits map-graph, map-ready, map-blocked, map-critical, map-layout, map-marks, map-pillars and map-ask. The map total stays as before.
• Reach walks shared: readyNow, idleFurniture and blockedOn each rebuilt the same "holds up" and "waits for" maps for one graph. They are now built once per graph, held in a WeakMap.
• Quadratic copies removed: two places in src/core/dependencies.ts copied the whole waiter list for every edge. They now append to it.
• Same answers: the page, the API and the MCP map return the same results as before. The existing map and dependency tests pass unchanged.

Before and after, warm, on the fixture

• map-ready: before the change it was 31 ms on the first read and 6 ms on the second. After it was 6 ms.
• map-graph and map-marks: the largest steps, at about 35 ms and 22 ms. I did not change them.

Test: test/map-speed.test.ts builds that fixture, checks that all eight phases are present, and asserts map is under 300 ms.

How to try it: open /trevato/forge/map on the preview and read the Server-Timing header. If the production map is still slow after this, the eight phases will show which step it is.

Not done: I did not find or fix a step that takes seconds, because none did on the fixture. I ran the tests that cover map.ts and dependencies.ts, mcp-size.test.ts, the gate, tsc and the design lint, and all passed. I did not run the full suite (the forge's check does). scripts/fast.ts reported the diff reaches 1,330 of 1,872 test files, so I picked the covering tests myself.

I couldn't reproduce the 2.5–3.6 s read, so I haven't found the step that takes seconds. The only speed-up I can show is in map-graph (about 88 ms to 50 ms on a body-heavy fixture), and that is not the fix @juniper asked for. A person needs to run the new phases against the real trevato/forge data to find the slow step.

What I tried

• I built pure-algorithm graphs at trevato/forge's size with readyNow, blockedOn and criticalPath:

- one chain through all 300 open issues, - 20 dense layers, - a closed chain, - a star.

• None took more than 50 ms, so holdsUpMap, waitsForMap and criticalPath are not quadratic on any of these shapes.
• The one step that does grow with the data is map-graph. getIssuesOfRepo pulls the body of every issue, about 3,300 of them, and the map page never shows a body. With 6 kB bodies seeded, map-graph took 88 ms.
• I did not measure the full phase breakdown at any larger body size, and I don't know trevato/forge's real body sizes.

What changed

• lean: true: mapPage now asks repoGraph for a graph without bodies. The new test checks that the lean and full graphs are identical apart from body. The API and MCP map still use the full graph, so their answers are unchanged.
• Phases: map-shown (openOnly) and map-words (wordFor and countWords) are named, so every step of the read now appears in the header. The map total is still emitted.
• Reach maps: a new test fails if a second reachOf call on the same graph rebuilds them.
• Speed test: the fixture now has 6 kB bodies. The 300 ms assertion passes with or without my changes, so it does not show that the slow case is fixed.

Where I disagree: I can't make the speed test fail on the base. I'd rather say that than add a fixture tuned to fail without a real cause behind it. The issue's 2.5–3.6 s may come from data the fixture doesn't have, or from the production machine.

Checking: I can't verify against the preview, because there is no trevato/forge repo there. All checking was local on the seeded fixture.

Tests run: tsc, the gate, the design lint, mcp-size and the map, dependency and timing tests.

The slow step on trevato/forge is the pillars' ask-to-live: the forge's own /api/v1/repos/trevato/forge/map reports asktolive;dur=1778–1842 of a 2.5–2.8 s read. Production deploys record every merged pull their commit contains, so deploy_pull keeps growing. That week had 992 merged pulls and 644 production deploys, so the old read pulled about 320k rows only to keep the first live time per pull. This pull fixes that step; Sentinel's review asked for exactly that.

What changed

• The fix (src/core/pillars.ts, new firstLiveOf): the week's production deploys are read once, in time order. For each pull, a binary search finds the first deploy after its merge, then up to 4 deploys are probed by deploy_pull's primary key, and the first is almost always the one. A pull none of those carry (not live yet, or behind a lagging deploy) reads its own deploy_pull rows instead, which are few or none. Three statements, however many pulls. The answer is unchanged: test/ask-to-live-batched.test.ts still checks it against the old per-pull reference, and the statement cap of 5 still holds.
• The test (test/map-speed.test.ts): it now seeds the real shape: 992 pulls merged over the week, each closing a pillar issue with a long body, and 644 production deploys that each carry every pull merged before them. It bounds map-ask under 100 ms as well as map under 300 ms.

- Without the fix, map-ask takes 1200–1980 ms and the test fails; with it, 33 ms, and the whole read is about 190 ms. - A new test checks that every pillar gets an ask-to-live figure, so the seed can't pass by reading nothing. A first draft of the seed did exactly that, because the fixture's body rewrite erased the pulls' Closes #N.

• Earlier commits on this branch: the reachOf WeakMap and the push helper are sound but unmeasured. They gave no gain on the fixture and were a guess, not the fix. The comment in src/web/pages/map.ts now says the ten named steps replace the old single map phase, and that map is still noted by hand as their total.

Not done

• No change to how deploy_pull is recorded. Recording only newly carried pulls would shrink the table, but the deploys TUI and carries on a run read it as it is today.
• The preview has no trevato/forge repository, so the claim is shown by the seeded test, not by a live page.

Checks: bun scripts/gate.ts, bun x tsc --noEmit and bun scripts/design-lint.ts pass. scripts/fast.ts named 1363 test files, over its budget, so I picked 63 covering ask-to-live, deploys, the map, pillars and milestones: 542 pass, 2 fail.

• map-layout-budget fails the same way with this change stashed: it is a 5 s timing test, slow in this sandbox.
• map-seed-timing failed only under load and passes when run alone.

The forge runs the full check on this push.

To try: bun test test/map-speed.test.ts test/ask-to-live-batched.test.ts. Once merged, curl -sD - -o /dev/null -H "authorization: Bearer $FORGE_TOKEN" "$FORGE_URL/api/v1/repos/trevato/forge/map" should show asktolive in tens of milliseconds.

🤖 Generated with Claude Code

The owner/name map is faster to build, and its reads are named so the slow steps can be found. On trevato/forge the page was spending about 1.8 s in one step: it read every deploy each pull ever had to work out when that pull first went live. That step is called ask-to-live, in src/core/pillars.ts, and it now looks up only each pull's first live deploy. The rest of the change:

• Shared walks: the reach walks in src/core/dependencies.ts are shared, and they no longer copy lists for every edge.
• Lean graph: the map loads only what it draws (src/web/pages/map.ts).
• Timing: each step of the read is named in the Server-Timing header.

test/map-speed.test.ts checks that the reach maps are shared and that a forge with many pulls and long issue bodies still builds its map within budget.

The previous check failed in 9 tests across shards 60, 64 and 66: tui-working, variants-deck, search-cache, proposal-token and quotas-storage. None of these files use the modules changed here. Run alone, and nine at a time in parallel, they all pass. The servers.stop error in variants-deck means its setup step didn't finish, which points to a slow, loaded check machine rather than this change. No test was edited. The branch has been brought up to date with main and pushed again.

Before the push, the gate, bun x tsc --noEmit and bun scripts/design-lint.ts all passed. scripts/fast.ts named 1,377 test files for the diff after merging main, well over its 5-minute budget, so I ran the files that cover the map instead: 30 map, sitemap, pillar, dependency and ask-to-live suites plus the five that failed, 191 tests with none failing.

Not done: no cache in front of the map. The point here was to make the cold read fast, not to hide it.

To try it, open /trevato/forge/map on the preview and read Server-Timing in the response headers.

🤖 Generated with Claude Code

Left #8381 open: 3 unticked items remain (Each of those steps is its own Server-Timing phase (map-graph, map-ready, map-blocked, map-critical, map-layout, map-marks, map-pillars, map-ask).; The slow step(s) are made fast without changing what the page draws (memoize by the graph's version, batch a per-issue read, or fix an algorithm that is quadratic); the pull names which step it was and its before/after.; A test builds a graph the size of trevato/forge (3,000 closed and 300 open issues, 600 edges, 10 pillars) and asserts the page's read is under 300 ms; the existing map tests pass unchanged.).