Performance trends
Daily measurement runs ↗| Measured | Revision | Native | Assessment | Evidence |
|---|
Measurement details and how to read the results
Changes you can act on
Current, previous and frozen Native compilers run the same workload on the same host. TypeRB Go compiles the identical source. Pure Go uses the three hand-written programs from the detailed comparison, with the daily inputs. Implementation differences contribute to the result. Lower time, memory and size are better. Differences below 5% are labelled “About the same”; this is a screening aid, not proof of equivalence or a statistical acceptance threshold.
Runtime ranges show the retained minimum and maximum. Trends retain up to 60 snapshots and show only the current measurement series. Input or measurement-policy changes start a new series.
Freshness without blocking development
Performance changes are measured once a day, around 06:23 JST, or on demand. GitHub scheduling may be delayed. An unchanged day needs no benchmark run. The daily update is independent of PR acceptance.
Numerical regressions are published. A failed measurement is shown explicitly; infrastructure failures preserve the last measured snapshot.
Read the measurements in scope
These are small workloads, not a general language score. Builds use clean output directories with a warm Go cache. Runtime includes fresh-process startup, with warm filesystem caches. Startup measurements include the launch harness; very short CPU and RSS observations may be below measurement resolution.
Peak RSS uses GNU time, not a summed process-tree sample. The allocation probes are separate from timing. Long-lived memory stability and full distribution size remain separate checks. Method and coverage ↗