> Benchmarking is the only thing you can really do in some cases. I think the complete opposite! Benchmarking is very difficult to get right and in some situat

> Benchmarking is the only thing you can really do in some cases. I think the complete opposite! Benchmarking is very difficult to get right and in some situations you couldn't really make a benchmark to test what you're interested in improving. Reading assembly can be objective if you know or look up the instruction latency/throughput of each instruction (or you have a tool provide it) and you can also use loop throughput analyzers (as the other commenter mentioned) that will try to predict the typical throughput for a given loop. IMO if you get used to looking at assembly it becomes obvious in the majority of cases whether there's performance left on the table. And "simplicity" does not equal "faster". Although for cold code, reducing its impact on i$ and d$ of the rest of the system is probably smart, so sometimes speed is not the only factor.