True, in practice there are some things that you can anticipate optimizing. However, there is such a thing as doing too much, before you know that there's a per

True, in practice there are some things that you can anticipate optimizing. However, there is such a thing as doing too much, before you know that there's a performance problem. Another good graphics/physics example is that you don't have to take the square root in a distance computation if you only care about the monotonically increasing ordering and not the exact distance. If you know that you will be dividing by magnitude or distance frequently, another optimization is to store the inverse of the magnitude instead of the original magnitude. That issue sometimes shows up in inner loops. But optimizations like that also don't have to be done up front because refactoring that kind of thing is relatively straightforward compared to switching out the underlying data structure or algorithm. My rule of thumb is that if I know I'm writing an inner loop, then I will bake in whatever best practices I already know about. Otherwise I'm going to write the feature first with generally sane architectural choices, and profile it later.