Unit testing your code’s performance, part 2: Catching speed changes
In a previous post I talked about unit testing for speed, and in particular testing for big-O scalability.
The next step is catching cases where you’ve changed not the scalability, but the direct efficiency of your code.
If your first thought is “how this is different from running benchmarks?”, well, good point!
An excellent starting point for performance is implementing a benchmark that runs automatically in CI, on every single pull request.
If you haven’t got that, you probably want to go do that first.
Once you have implemented CI benchmarks, they will typically run when you submit a pull request or the equivalent.
And if you’re doing performance work, that’s hopefully just a formality, as you likely have been benchmarking your code locally as you work.