Testing the compiler optimizations your code relies on
In a recent article by David
Lattimore,
he demonstrates a number of Rust performance tricks, including one that involve writing code that
looks like a loop, but which in practice is optimized down to a fixed
number of instructions. Having what looks like an O(n) loop turned
into a constant operation is great for speed!
But there’s a problem with this sort of trick: how do you know the
compiler will keep doing it? What happens when the compiler’s next
release comes out? How can you catch performance regressions?
One solution is benchmarking: you measure your code’s speed, and if it
gets a lot slower, something has gone wrong. This is useful and
important if you care about speed. But it’s also less localized, so it
won’t