Perf next steps: render path is optimized, JS main thread is now the bottleneck

[DFearing]

Summary

Empirical comparison of the major perf checkpoints since the upstream merge-base, captured 2026-05-02.

• Render-path work is essentially complete. Baseline → main: 47 → 112 FPS at 1× CPU (+138%) while simultaneously rendering 3× as many canvases. Per-canvas effective throughput went up ~7×.
• PR Perf: complete Pixi migration + sim-manager polish (12 issues, 1 PR) #36 (full Pixi migration) was the single inflection point — it accounts for almost the entire visible win. Everything before was net-flat or slightly regressed; everything after (perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43 visibility-gating + hit-test, perf(pixi): shared renderer migrates to multiView (rebased onto main) #45 multiView) showed no measurable improvement in this scenario.
• Under high CPU load (4× throttle), the perf work has barely moved the needle (10 → 12 FPS). Long-task blocking time stays at ~80s out of every 90s measurement window. The bottleneck has clearly moved from the render path to the JS main thread.

Methodology

• Bench: bench/run-bench.mjs (Playwright + CDP, headless Chromium with --disable-frame-rate-limit --enable-precise-memory-info)
• 5 stacks: baseline (59ccf4e), PR Perf: Pixi agents layer + glyph atlas (closes #12) #31 (df3bd94), PR Perf: complete Pixi migration + sim-manager polish (12 issues, 1 PR) #36 (680cb12), PR perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43 (ed97e12), main / PR perf(pixi): shared renderer migrates to multiView (rebased onto main) #45 (c20d844)
• Workload: concurrent sim scenario, 3 sessions, workload-matched (3 canvases visible simultaneously)
• 1 rep × 2 throttles per stack, 30s warmup + 90s measurement
• Raw data: bench/results/perf-comparison.jsonl (10 rows)
• Chart regenerator: bench/perf-chart.mjs

Results

Drag bench/results/perf-chart.png into this issue to attach the chart.

Stack	FPS @ 1×	p95 @ 1×	FPS @ 4×	p95 @ 4×	Long-tasks @ 4×	Heap peak
Baseline (59ccf4e, 1 canvas)	47	25 ms	9.8	120 ms	87.2 s	23 MB
PR #31 (df3bd94)	61	34 ms ⚠️	10.4	137 ms ⚠️	79.9 s	44 MB
PR #36 (680cb12)	115	19 ms	11.2	121 ms	80.6 s	44 MB
PR #43 (ed97e12)	112	19 ms	11.6	115 ms	80.9 s	42 MB
main / PR #45 (c20d844)	112	19 ms	11.5	118 ms	80.9 s	43 MB

⚠️ PR #31's partial Pixi migration regressed p95 frame time at both throttles — half-Pixi/half-DOM was worse than either alone. The win required completing the migration (PR #36).

Where the wins did NOT come from (and why)

The bench shows zero improvement from #43 and #45 — but that's a measurement-design issue, not a sign the work was wasted:

• perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43 visibility gating (IntersectionObserver + document.visibilityState) — all 3 bench canvases are on-screen, so the gating never fires. Real value is when canvases scroll out of view.
• perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43 per-pixel hit-test (EventBoundary) — correctness/UX fix, not a throughput change.
• perf(pixi): shared renderer migrates to multiView (rebased onto main) #45 multiView — drops a readPixels GPU↔CPU sync and per-viewport RenderTexture. Wins are in GPU memory + GPU time, neither of which the bench captures. The heap delta we do see is dominated by canvas count, not RenderTexture.

These optimizations may still be load-bearing; the bench just isn't designed to surface them. See "Direction" item 3 below.

Direction for future perf work

The render path is mostly tapped out for this workload. To meaningfully move 4× throttle FPS or scale beyond 3 concurrent canvases, the next gains have to come from the JS main thread.

In priority order:

1. Profile long tasks at 4× throttle (cheap, high-information)

80s of blocking time over a 90s window means almost everything is one long task. Without knowing what's in them, further optimization is guessing. Concrete steps:

• Run a representative `concurrent` workload at 4× throttle with the Chromium Performance recorder attached
• Identify the top 3 long-task call stacks
• Likely suspects: sim event ingestion, React reconciliation, scene-graph diff
• File a separate sub-issue per hot path with the call-stack screenshot

2. Reduce React reconciliation cost

The bench captures ~3500-3800 React commits per 90s window with 3 canvases — that's ~13 commits/sec/canvas. Worth investigating:

• Are panel state changes (Messages, Files, $Cost, Timeline toggles) triggering full-tree reconciliation that should be scoped to one panel?
• Is per-event sim ingestion fanning out into multiple React state writes when one batched write would do?
• Move panel state into separate context providers so canvas-state changes don't reconcile the panel subtrees and vice versa

3. Move sim event ingestion off the main thread

SimulationManager's shared rAF processes events for all sessions in lockstep on the main thread. Web Worker for ingestion (relay events → diff → postMessage minimal updates to React) would free the main-thread budget that's currently spent on JSON parsing + state diffing.

4. Add bench scenarios that exercise the optimizations this run missed

The current bench understates #43 and #45 because the scenario is "everything visible, all the time". Suggest adding:

• Off-screen scenario — N canvases mounted, only K visible (others scrolled out / behind another panel) — measures perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43's visibility gating
• GPU memory snapshot — Performance.getMetrics GPU process memory delta per measurement window — measures perf(pixi): shared renderer migrates to multiView (rebased onto main) #45's multiView heap savings
• Apples-to-apples + workload-matched in one run — currently we only have one or the other; baseline's 1-canvas datapoint is the only apples-to-apples cell

5. Measure Pixi's residual per-frame blit

Per #45's caveat: WebGL backend's GlRenderTargetAdaptor.postrender still does canvasSource.context2D.drawImage(contextCanvas, ...) per render target, per frame. Cost is unknown but bounded. A focused micro-bench (mock scene, vary canvas count, measure render() wall time) would tell us whether it's worth chasing WebGPU.

Tracking

• This bench rerun supersedes Re-run benchmark matrix (track 2nd-pass measurements) #37's first-pass numbers for the recent stacks.
• Files left in tree (uncommitted): `bench/perf-chart.mjs`, `bench/results/perf-comparison.jsonl`, `bench/results/perf-chart.png`, `bench/results/perf-chart.html`. Worth committing the chart script to a follow-up branch if we want it as standing infrastructure.

🤖 Generated with Claude Code

[DFearing]

Update: apples-to-apples comparison (1 canvas, 1 session, both stacks)

Added a second bench cell pair — baseline and main both at `--sim-count 1` — to remove the workload-difference confound. The numbers reframe the story significantly.

Metric	Baseline (1 canvas)	main / PR #45 (1 canvas)	Δ
FPS @ 1×	48.6	565.1	+1063% (~11.6×)
FPS @ 4×	10.5	35.8	+241% (~3.4×)
p95 frame time @ 1×	23.9 ms	6.5 ms	−73%
p95 frame time @ 4×	115 ms	47 ms	−60%
Long-task blocking @ 4× (90s window)	87.8 s	0.35 s	−99.6%
Heap @ 1×	22 MB	16 MB	−27%

Raw rows in `bench/results/perf-comparison-1sim.jsonl`. Chart updated at `bench/results/perf-chart.png` (now has a workload-matched section + an apples-to-apples section).

What this changes about the conclusion above

The headline finding in this issue — "the bottleneck has moved to the JS main thread" — was true for the 3-canvas workload but misleading as a general statement.

Per canvas, the perf work has cleared almost all main-thread bottlenecks:

• 4× throttle long-task blocking time dropped 99.6% (87.8s → 0.35s out of a 90s window)
• 4× throttle FPS improved 3.4× (not the 17% the workload-matched data suggested)

The real bottleneck is multi-canvas scaling, not main-thread work in absolute terms. Going from 1 canvas to 3 canvases consumes almost all of the per-canvas gains. That's a different kind of problem.

Revised direction

The priority list above is still mostly right, but the framing should shift:

What stays

• Profile long tasks at 4× throttle (workload-matched 3-canvas) — still item Multi-session UI + wire-format simulator #1. Now reframed as "why does adding canvases 2 and 3 reintroduce so much main-thread work?" rather than "what's the residual main-thread cost?"
• Reduce React reconciliation cost — the ~3500 commits/90s number is from 3 canvases. At 1 canvas it's ~270-1450 commits/90s. So per-canvas commit count grows roughly linearly with canvas count, which it shouldn't if subtrees were properly isolated.
• Move sim event ingestion off the main thread — even more attractive now: it would help the multi-canvas case directly without re-architecting the per-canvas render path that's already performing brilliantly.

What's downgraded

• "React reconciliation cost" as a per-canvas concern is less urgent. The single-canvas reconciliation budget is comfortable.

What's added

• Multi-canvas work-sharing audit — explicitly look for places where N canvases each run an expensive operation that could be shared:
  • Scene-graph diff (does each canvas independently diff its own state, or does the SimulationManager do it once and broadcast?)
  • Hit-test boundary updates (PR perf: Pixi follow-ups — visibility hook + per-pixel hit-test (closes #33, closes #34) #43 added per-viewport `EventBoundary` — verify these don't overlap in work)
  • rAF callbacks (PR Perf: complete Pixi migration + sim-manager polish (12 issues, 1 PR) #36's shared rAF — confirm it's still single-source-of-truth, not one rAF per canvas)
• Add an N-canvas scaling chart to the bench — measure the same stack at sim=1, 2, 3, 5, 10. If the curve is super-linear, that's the regression to chase.

[DFearing]

Direction item 1 — first pass complete.

Captured a 90s CPU profile against main (98df60b) at 4× CPU throttle on the same concurrent 3-session workload. Reproduced the issue's bench-level numbers (79.8s of long tasks per 90s window, 9.5 fps).

Top hot paths and the sub-issues filed for each:

1. perf: Canvas2D BloomRenderer is 49% of all CPU at 4× throttle #53 — Canvas2D BloomRenderer.apply is 49% of all CPU. 4 drawImage calls + a ctx.filter='blur(12px)' per frame. Single biggest win.
2. perf: Canvas2D label/text draws ≈ 6% of CPU at 4× throttle (per-frame redraw) #54 — Canvas2D label/text/hex-grid draws ≈ 6% of CPU. Glyph atlas + cached hex-grid would pay this off.
3. perf: message-feed virtualization measureRef thrashes ≈ 2.4% of CPU #55 — Message-feed virtualization measureRef thrash ≈ 2.4% of CPU. Per-item ref callbacks triggering React re-commits in a loop. Touches direction item 2 (React reconciliation) too.

Methodology finding: the bench navigates without ?renderer=pixi, so it (and this profile) measures the Canvas2D AgentCanvas path, not the Pixi WebGL path. PR #43's visibility gating and PR #45's multiView only affect the Pixi path — the bench can't see them, which explains their zero measured impact. The "PR #36 inflection point" must come from infrastructure shared by both renderers, not the Pixi migration itself. Worth deciding whether the bench should switch to ?renderer=pixi or whether the Canvas2D path is the production-relevant one to measure.

Unattributed: 21.4% of CPU sits in V8's (program) bucket (GC / deopts / parse / compile). Needs a heavier CDP Tracing.start pass with v8 categories — not actionable from this CPU profile alone. Filing as a follow-up only if direction item 2 doesn't already absorb it.

Tooling added: bench/profile-long-tasks.mjs and bench/breakdown-by-caller.mjs. Profile artifacts in bench/results/long-tasks-*.{cpuprofile,md,json}. PR incoming.