I think I could use a slightly more detailed explanation of what it is and how it works at the high level. The website doesn't fully explain it.<p>e.g. The about page, as of this writing, does not say anything about the project.<p><a href="https://otava.apache.org/docs/overview" rel="nofollow">https://otava.apache.org/docs/overview</a>
Change Detection for Continuous Performance Engineering: Otava performs statistical analysis of performance test results stored in CSV files, PostgreSQL, BigQuery, or Graphite database. It finds change-points and notifies about possible performance regressions.<p>You can also read "8 Years of Optimizing Apache Otava: How disconnected open source developers took an algorithm from n3 to constant time" - <a href="https://arxiv.org/abs/2505.06758v1" rel="nofollow">https://arxiv.org/abs/2505.06758v1</a><p>and "The Use of Change Point Detection to Identify Software
Performance Regressions in a Continuous Integration System" -
<a href="https://arxiv.org/abs/2003.00584" rel="nofollow">https://arxiv.org/abs/2003.00584</a>
(and I guess this blog post <a href="https://www.mongodb.com/company/blog/engineering/using-change-point-detection-find-performance-regressions" rel="nofollow">https://www.mongodb.com/company/blog/engineering/using-chang...</a> )<p>(<a href="https://en.wikipedia.org/wiki/Change_detection" rel="nofollow">https://en.wikipedia.org/wiki/Change_detection</a> explains what's change detection)
If you've had the problem it solves you don't really need an explanation beyond "Change Detection for Continuous Performance Engineering" I think.<p>Basically if I'm reading it correctly the problem is you want to automate detection of performance regressions. You can't afford to do continuous A/B tests. So instead you run your benchmarks continuously at HEAD producing a time series of scores.<p>This does the statistical analysis to identify if your scores are degrading. When they degrade it gives you a statistical analysis of the location and magnitude of the (so something like "mean score dropped by 5% at p=0.05 between commits X and Y").<p>Basically if anyone has ever proposed "performance tests" ("we'll run the benchmark and fail CI if it scores less than X!") you usually need to be pretty skeptical (it's normally impossible to find an X high enough to detect issues but low enough to avoid constant flakes), but with fancy tools like this you can say "no to performance tests, but here's a way to do perf analysis in CI".<p>IME it's still tricky to get these things working nicely, it always requires a bit of tuning and you are gonna be a bit out of your depth with the maths (if you understood the inferential statistics properly you would already have written a tool like this yourself). But they're fundamentally a good idea if you really really care about perf IMO.
it is basically a “performance regression detector” It looks at a time series of benchmark results (e.g. test runtime, latency, memory usage across commits) and tries to answer one question: did something actually change, or is this just noise?<p>in a performance critical project I am working on, I had a precommit hook to run microbenchmarks to avoid perf regressions but noise was a real issue. Have to to try it to be sure if it can help but seems like a solution to a problem I had.
If your benchmarks are fast enough to run in pre-commit you might not need a time series analysis. Maybe you can just run an intensive A/B test between HEAD and HEAD^.<p>You can't just set a threshold coz your environment will drift but if you figure out the number of iterations needed to achieve statistical significance for the magnitude of changes you're trying to catch, then you might be able to just run a before/after then do a bootstrap [0] comparison to evaluate probability of a change.<p>[0] <a href="https://en.wikipedia.org/wiki/Bootstrapping_(statistics)" rel="nofollow">https://en.wikipedia.org/wiki/Bootstrapping_(statistics)</a>
It's hilarious that the about page doesn't tell you anything about the project