Mohamed Ashraf Elsaed

A benchmark gate that catches small regressions

By Mohamed Ashraf ElsaedPublished 2 min read

A benchmark you run once is a screenshot. A benchmark that fails a pull request is a guard. This post describes the regression gate in Aletheia: what it measures, how its baseline was set, and what it cannot tell you.

The gate

bun bench/gate.mjs builds a seeded synthetic corpus of 50,000 rows across ten topics, runs 100 queries five times, and compares two numbers with a stored baseline:

The check fails if Recall@5 falls by more than 0.01, or if p95 latency rises by more than 20 percent. The latency check is enforced only when the baseline p95 is at least 5 ms.

Why seeded

Random data gives a different answer each run, so a drop could be noise. A fixed seed makes the corpus identical every time. Any change in the numbers comes from the code.

Calibrating on the real runner

A baseline set on one machine can fail on another. Two runs on a GitHub runner gave p95 latencies of 7.268 ms and 7.294 ms against the 7.759 ms baseline, about 6 percent below it. The 20 percent margin was chosen, and two runs are too few to prove it is the right width. The baseline file records the machine only as linux x64 bun 1.3.10.

What the gate cannot tell you

What I would do differently

I would add a trend check. Against a fixed baseline, a slowdown that creeps up in small steps passes every run until the total passes 20 percent.

Sources

This post was drafted with AI assistance. I reviewed every claim and ran the commands shown.

About the project: Aletheia.

Mohamed Ashraf Elsaed
Mohamed Ashraf Elsaed
Technical Lead at Convertedin, Cairo. I build tools for AI coding agents and write about Laravel, Node and engineering.