Performance
This dashboard publishes synthetic compiler phase probes and deterministic scaling diagnostics. They help locate compiler regressions; they are not representative applications and do not measure compiled-program runtime performance. Representative RUE-901 scenarios will remain a separate metric family and headline.
Compilation time by measured commit
Absolute milliseconds. Lower is better. Select a point or choose two commits below.
new measurement segment
Compiler phases
Aligned to the same measured commits. The aggregate compile timer is excluded.
What changed around these measurements
Measurement and runner changes
Explore the full performance evolution
Long-term performance evolution
This view shows normalized compile speed, not milliseconds. The first measurement in each connected machine segment is assigned 100, and higher is faster: roughly, 105 means compile speed is 5% above that segment’s baseline. Faint points are measurements; solid daily or weekly trends include observed variation. Compare direction only within a connected segment. Do not rank machines by their indexes or interpret a change across a disconnected measurement boundary.
Raw measurements, gaps, and coverage
Other diagnostic views
Workload measurements
Absolute time for each benchmark makes a localized regression visible.
Memory and output size
Latest workload metrics
Synthetic compiler scaling diagnostics
Generated phase probes show whether latency and peak-memory growth outpace input growth. They are not representative applications and are excluded from the aggregate headline.
Representative compiler build/query scenarios
Cold root builds and fixed CompilerSession edits use one tracked multi-module project. They measure compiler work, not generated-program runtime, and remain separate from phase probes and scaling diagnostics.
Measurement records, coverage, provenance, and raw samples
Technical evidence for reproducing or auditing a point. Fields are labeled; raw samples remain available without exposing serialized objects.
Methodology
Benchmarks run automatically against trunk on Linux x86-64, Linux ARM64, and macOS ARM64 runners. Each point represents a measured commit. When commits land faster than a run completes, an in-flight run may be cancelled in favor of the newest commit.
The primary charts use absolute time on one machine. Comparisons only cross points that the benchmark model marks comparable, and their classification accounts for observed variation. A disconnected line begins a new baseline; it does not imply that compiler performance jumped. Normalized indexes are reserved for comparing the direction of change within each machine because absolute timings from unlike machines should not be overlaid.