Thank you for writing a clear explanation of how false positive rates determine your minimum change threshold. I've found it surprisingly difficult to explain this to developers/QA's without a basic statistical background.

What makes the situation worse, which you didn't mention, is that developers like to write a suite of benchmarks, each of which can result in a false positive regression. So even if the FP rate of an individual benchmark is <1%, you can easily end up at 10% FP rate if your suite is large enough.

I think the best way to do this would be to use something deterministic like instruction counts for the actual pass/fail. You can include wall time for information.

Great write up! The use of coefficient of variation to detect instability seems reasonable. I've been done performance analysis of actual request traffic (not for benchmarking) to gauge the level of noise in a noisy-neighbor environment, and I believe I looked into using CoV for this and found it wasn't particularly reliable for my purposes.

I'd love to learn about more statistical techniques for doing such analysis. For example, one thing I looked into was correlating tenants and identifying a likely culprit, and it's often not just a matter of absolute request volume. If multiple tenants' latencies increase at once, it's usually because one of them started doing something. But its hard to isolate what that is, when there are many different types of workloads with unpredictable performance impact.

I've been burnt by performance gates on GitHub Actions. One random timing spike and the whole PR turns red. The coefficient of variation math here nails why: GitHub Actions shows a 2.66% CV, which means a 2% performance gate gives you a 45% false positive rate (basically every other run flags a fake regression). No wonder developers stop trusting the check. In my experience the only way to make benchmarks actionable is to run them on deterministic bare-metal runners, whether CodSpeed's or something you host yourself.