Performance trend

Every push runs perf/run_bench.py, which drives three lanes — compile/link/lower, actor start latency, and a per-stage compiler profile of one representative file — and appends one line to a JSONL trendline. This page plots that file.

Every metric in the trendline gets a chart. The page reads the row families out of the data rather than carrying a list of its own, so a family the bench starts emitting appears here on the first run that publishes it. Today’s families:

• compile.<file>.* and compile.totals.* — one row per compiled unit plus the corpus totals: instructions, mach instructions, mcode and fragment bytes, literals, guards.
• link.* / lower.* — the linked image and the lowered fragment.
• kernels.* — nine execution kernels (numeric loop, closure calls, record churn and growth and lookup, array sweep, string build, text search, GC churn). These are the only rows that measure how fast the emitted code runs.
• switching.* — what an actor switch costs, over a fixed ping-pong flood.
• gc.*, actor_memory.*, runtime_memory.*, start.* — heap traffic, live-fleet footprint, and actor start latency.
• stages.* — the per-stage compiler profile of one file. Currently absent: its lane hangs, and the rows return here on their own once it is fixed.

Two measurement classes, and the difference is the whole point (plans/measurement-suite.md §2.1):

• counter — derived from a count the runtime already keeps, or a deterministic property of an artifact. Reproduces bit-for-bit on a loaded machine. perf/bench_gate.py holds a ceiling over these, so a regression here is a red build.
• wall — a clock reading. Contended. Reported here, never gated. Runs taken on a loaded machine are marked; treat their wall points as order-of-magnitude only.