Historical record · 100 daily runs

The same measurement, every day since May.

A single benchmark is a snapshot; a run every day on the same hardware is a record. This is that record — 100 runs from 2026-05-11 to 2026-08-22, with every point linking to the GitHub Actions run that produced it.

Runs
100
First
2026-05-11
Latest
2026-08-22
Host
Xeon Platinum 8259CL @ 2.50GHz
Instance
t3.medium
liboqs
0.15.0
Over time

Pick a metric and watch it move — or not.

Up to four algorithms at once, so no colour is ever reused for two lines. Breaks in a line are runs with no measurement.

Mean latency · µs · keygen · 100 runs

Measured points only. A break in a line is a run with no measurement — it is not smoothed over, and there is no value between two runs.

Summary

First measurement, latest, and everything between.

The default selection. Change is first-to-last; read it against the observed range in the next column, not on its own.

AlgorithmFirstLatestChangeObserved rangePointsGaps
ML-KEM-512ML-KEM13.7 µs · 2026-05-1113.8 µs · 2026-08-22+0.7%13.3 µs – 26.9 µs1000
ML-KEM-768ML-KEM18.8 µs · 2026-05-1121.1 µs · 2026-08-22+11.9%18.0 µs – 35.5 µs1000
ML-DSA-44ML-DSA32.3 µs · 2026-05-1137.4 µs · 2026-08-22+15.8%31.3 µs – 59.4 µs1000
ML-DSA-65ML-DSA52.3 µs · 2026-05-1192.0 µs · 2026-08-22+75.9%50.1 µs – 93.0 µs1000
Why there is no line between two runsOther benchmark publishers interpolate: they fit a curve through measured points and read a value off it at whatever operating point you ask for. We do not, and the gaps in these lines are the visible consequence. A run that did not happen produces no point, and the line breaks rather than being drawn through a value nobody measured. If you need a figure for a date between two runs, the honest answer is that we do not have one — and the API says the same thing in its own payload.
The spread is larger than the trend, and that is the findingAcross these 100 runs the observed range on a single algorithm’s keygen mean is 86103% of its own minimum. Every first-to-last change in the table above sits inside that band. So does the largest of them: ML-DSA-65 reads +76% end to end, but it alternates between roughly 50.1 µs and 93.0 µs from one run to the next rather than drifting — the endpoints only say which mode each happened to land in.

The cause is the host, not the algorithms: t3.medium is a burstable instance and CPU steal has ranged from 0.13% to 10.51% across the record. We publish this rather than smooth it, and it is the honest reason not to read a trend line here as a performance change. Comparisons between algorithms measured in the same run are sound — that is what compare is for. Detecting real change over time would need a dedicated instance, and until there is one this page is a record of what we measured, not a claim about what changed.
Take the data

The whole series, as JSON.

This page reads the same public endpoint you can — no privileged access to its own data.