Measured performance
Workload history
Benchmark history across releases and merges to main, with source and raw evidence for every point.
Loading benchmark history…
Measurements
● Main◆ Release■ Merged PR○ Source patch / other↕ Confidence interval
All plotted values and provenance
| Source / markers | Environment | Median | Uncertainty | Measured | Evidence |
|---|
Historical release and merged-PR coverage
Runs without measurements
Method & evidence
Lower values mean less time or fewer reads for the selected workload. They do not describe overall application performance.
Reading the lines and uncertainty
All recorded environments and configurations are shown by default for the selected workload and measurement. Use the filters to narrow the comparison. Colors and line patterns distinguish configurations; each line connects only measurements with compatible workload semantics, machine/OS, compiler, build profile and recorded settings. Differences such as injected network latency remain separate configurations. Source dependency changes remain part of the code being measured.
Revisions are evenly spaced in source-date order; horizontal distance does not represent elapsed time. Longer histories scroll horizontally to keep neighboring revisions distinct. Dates remain visible in the labels and details, while the table separately records when a run was measured. Uncommitted source patches use the known study date. A line is a visual guide between recorded values; gaps remain unknown. Where a revision has repeats, the line follows its first recorded run and all repeats remain visible.
Time points show Criterion's median and its confidence interval. That interval describes uncertainty within the run, not between machines or days. Event reads are exact instrumented getter calls from one untimed fixture execution, with no statistical interval. Hover, focus or select a point, or use its table row to inspect provenance.
Collection and historical coverage
CPU, OS and target architecture are shown where recorded. Machine identities and recorded settings remain part of the configuration; missing environment details are not inferred. Local, hosted-CI and dedicated-runner provenance remains in each point's details and does not exclude runs from the default view. Shared-machine contention can affect timing even on the same CPU.
The coverage catalog tracks Cargo publications and merged PRs, including pending, failed and unsupported requests. An older revision that cannot run an equivalent harness gets a reason instead of a substituted point. July reference timings from other conditions have not been converted into points.
What the local study measures
The DAG fixtures use an in-memory event map without property operations. Clone-included and borrowed-fixture timing boundaries are separate series. Layer workloads include comparison; the candidate's full batch preparation is separate from the old layer drain, even where its original raw name still said diamond_chain_drain.
The end-to-end lanes use real Sled nodes and local process transport. Repeated local commit, subscriber, and 100/1,000-event catch-up measurements are retained separately. This study does not cover every historical release, public-network latency, multiple unresolved meets, saturation, or broader lineage and bridging costs.
Local study evidenceDurable CI dataLocal comparison JSONLocal backfill JSON
CI history loads directly from the versioned benchmark-data branch. If it cannot be reached, the page reports that gap and keeps the checked-in local evidence available.