[silvestrov]

micro benchmarks are especially problematic in real-world code where you load stuff from random addresses in memory.

If the code after the cast is blocked on a memory load, then you have a lot of free instructions while the cpu is waiting for the memory load to complete. In this case it doesn't matter if the cast is free or takes a handfull of instructions.

Sometimes code becomes faster by using more instructions to make the data more compact so more of the data stays in the caches.

[Cthulhu_]

Microbenchmarks are only valid for the one function under test, and only on the current machine; they're all right for optimizing on particular hardware, but not so much to go out into the world and go "X is faster than Y"

That said, I did like this website where you could set up JS benchmarks, they would run on your own machine and you could compare how it ran on other people's systems. It wasn't perfect, but it gave a decent indication if X was faster than Y. Of course, it's a snapshot in time, JS engines have gone through tons of optimizations over the years.

[silvestrov]

My point is that the context of the function can invalidate a microbenchmark completely.

If you only call this function once in a while, then the context is more important than the function.

You can only ignore the context when you do video decoding or matrix inversion or similar "context free" long running code.