I would much rather deal those "myths" than with the class of myths surrounding i++ being faster/lower than ++i or any of the non-sense around divisions.

At least people claiming something will be optimized away can readily be empirically tested in a way that most will listen to. I have no problem testing the / operator, but I have never had holders of such beliefs accept my results, but people claiming something like "virtual function calls can be optimized away" can handle it when I can demonstrated that inside a single binary they can be but at places like library boundaries they cannot.

> I would much rather deal those "myths" than with the class of myths surrounding i++ being faster/lower than ++i or any of the non-sense around divisions.

This is one area I dislike in C and C++ culture, there is this tendency to micro-optimize code like that, without even profiling it, or it causing an actual impact on the application being built.

So one ends up with endless bike shedding discussions about how to write code, instead of writing it.

That is a facet of programming culture. So many programmers in so many languages have their silly myths.

A few years some Ruby dev said that declaring methods without parenthesis would let the Ruby parser parse method declarations faster. The dev never even measured, he just thought the parens were ugly and a ton of gem devs removed parens claiming a speed up. It wasn't until a few years later that someone benchmarked it and determined that there either was no difference or that it cost just the tiniest amount to remove them.

Those are the things that the compiler can do to optimise your program by a few x. The sorts of optimisations that it can't do are things like picking a different algorithm, or reorganising the layout of a class so that it or multiples of it can fit within a cache line.