the long view

every merged commit, one row each. every number is a deterministic count, so any machine extends the series and none can smear it. ci measures the commit under test, appends it as the last point, and redraws this chart on every pull request; what merges is what you see here.

the welfare line is recorded, not recomputed. the score a commit shipped with is a fact about that commit, and replaying history against today's baseline would rewrite it. it is also the one line with a rule attached: it may not go down. a change that would lower it gets optimized until it holds. every other number here is a softer gate — a counter may worsen only if something else improved, and each worsening needs a written sentence naming why.

each line is scaled to its own range, because an instruction count and a byte peak cannot share an axis and stay readable. what the chart shows is shape — which way a number went and when it stepped. the horizontal axis is commit order, because commits are what the ratchet acts on. a line starts where its counters start: the schema grew with the project, so the compile lines reach back to the first recorded row while the welfare line begins where the score was first written down.

how each line is derived, from the code that draws it. run instructions is instructions + encode_instructions in thousands — retired instructions for the decode and encode veins, counted under callgrind and pinned in bench/instructions_golden.txt. it is what a run costs. run memory is oneshot_arena_peak_bytes, the high-water mark of the one-shot vein's arena. binary size is the decoder's .text section in bytes, from bench/text_golden.txt — its own only, since every binary links the same runtime and summing them would count it four times. compile work is compile_rounds + compile_visits + emitted_lines — fixpoint rounds, expressions the fixpoint looked at, and lines the emitter wrote. compile memory is compile_peak_bytes. welfare is the score the commit shipped with.

every one of these is an exact integer a rerun reproduces, which is what lets them be diffed rather than eyeballed. the memory and size lines reproduce on any machine; the instruction line reproduces on one compiler, because instruction count is what an optimiser's inlining choices move most, and a toolchain change steps every row of it at once.

the instruction line is here because its absence hid a real regression. between 2026-07-27 and 2026-08-07 the decoder went 2,545,249,871 retired instructions to 2,762,364,162 — eight and a half per cent, matching a wall-clock slowdown measured separately — while every allocation counter stayed byte-identical. the chart used to carry an allocation line named for speed, and it could not say so.

counterswhat every commit costs

the chart shows shape; these are the numbers themselves, as ci recorded them on the last push to main. each is deterministic, so a change here is somebody's deliberate edit rather than weather. select a row to read what the counter measures and why it is worth watching.

the numbers above were measured by hand on a named day. these are measured by ci on every push to main, and they are the deterministic ones — allocation counts, arena blocks, rewind iterations, kernel presence, and what the compiler spent deciding and emitting. a noisy runner cannot move any of them, so a change in this panel is somebody's deliberate edit rather than weather. select a row to read what the counter measures and why it is worth watching.

the counts rise across the span because the corpus does: the basket gained a hundred-thousand-element accumulator and a fifty-kilobyte text workload, the encode vein gained lib/json, and each widening was re-baselined so the score read the same either side. these are the cost of the work as it stands each day, not of a frozen file.