Performance on main
The Main Performance dashboard charts every game’s frame time, GPU time and render counts at each merge to main. It measures them against the goal in issue 862: every game holds 144 fps, so no more than 1% of its frames take longer than 6.94 ms. To see the numbers, sign in to claude.ai. A signed-out visitor sees the page without its data.
What the dashboard shows
Section titled “What the dashboard shows”The dashboard has the following parts:
- A line saying what the monitor is measuring now.
- The latest head, one card per game, with its p50 frame and its share of frames over the 6.94 ms budget.
- The regressions filed against
main, each linked to its issue and to the merge that caused it. - One chart per metric, one line per game, over every measured head. The frame, CPU and GPU charts draw the 6.94 ms line.
- A table with one row per head and game, and each value’s change from the previous head.
How a head is measured
Section titled “How a head is measured”A monitor session watches main. When main moves, it measures the new head on one machine: an AMD Ryzen 9 3900X, an RTX 3070 and a 2560 by 1080 display at 143 Hz. It checks out the head, installs, builds, and profiles each game under games/ with vsync and the CPU sampler off, because the sampler slows every frame:
pnpm game play profile --project mmorpg --gpu --no-vsync --render --no-cpu --budget 6.94Each game runs three times, and each value on the dashboard is the median of the three runs. Heap sampling slows frames too, so one more run with --alloc supplies the garbage per frame.
The command opens a headed Chromium fullscreen, so only one run holds the display at a time. Other agents share the machine, and their load can swing timings by about 20%. The table’s load column records how many other node and chrome processes were running.
When a head counts as a regression
Section titled “When a head counts as a regression”The monitor compares each game’s row with the previous head’s row:
- A count that rises is a regression when the new head’s lowest of three runs is above the previous head’s highest. Counts are draws, triangles, instances per pass, program switches, shader links and uploads, each a mean per frame, so they wobble slightly between runs.
- A timing is flagged when its median is more than 10% worse than the previous head’s. A second set of three runs must confirm it before it counts as a regression.
- A game with more than 1% of its frames over 6.94 ms is flagged against the budget. A player sees each of those frames as a hitch, even when the p50 frame is well within budget.
When more than one merge landed since the last head, the monitor measures each merge commit on git log --first-parent to find the one that caused the regression. It then files one issue for each merge that caused a regression, with every game and metric that merge moved. The issue title starts with “Perf regression:”, its first line is “Refs #862”, and it carries the labels bug, follow-up, and engine or game. The body links the merge and its pull request, tables the numbers before and after, and gives the commands that reproduce them.
Where the numbers live
Section titled “Where the numbers live”The numbers live in the artifact’s own data store, not in the repository. Only the artifact’s owner writes to the store, and every signed-in visitor can read it. The store holds the following collections:
| Collection | One document per | Holds |
|---|---|---|
heads |
measured head | The head’s SHA, its merged pull requests, its commit time as order, and one row per game: the medians, plus each run’s timings and counts for the regression rule. |
regressions |
filed regression | The game, the metric, the numbers before and after, the merge, its pull request and the issue. |
meta |
two: info and status |
info holds the unit of each metric, as the profiler states it, and the command that measured the latest head. status says what the monitor is measuring now. |
Maintain the dashboard
Section titled “Maintain the dashboard”Any Claude session on the owner’s account can update the dashboard by its URL:
- To add or fix a row, write to the store with the
ArtifactDatatool. The page re-renders for open viewers, and the page itself stays unchanged. - To change the page, read it with the
Artifacttool’sreadaction, edit that copy, and publish it with the sameurl. The link and the stored numbers stay the same.