[suyjuris]

It is also important to consider that better performance also increases your productivity as a developer. For example, you can use simpler algorithms, skip caching, and have faster iteration times. (If your code takes 1min to hit a bug, there are many debugging strategies you cannot use, compared to when it takes 1s. The same is true when you compare 1s and 10ms.)

In the end, it is all tradeoffs. If you have a rough mental model of how code is going to perform, you can make better decisions. Of course, part of this is determining whether it matters for the specific piece of code under consideration. Often it does not.

[Quarr]

This is definitely not something that should be overlooked. Choosing a more mathematically optimal algorithm might be 2-3x faster in theory (at the cost of more complexity). If you're executing that algorithm a lot, to the point where a 3x speedup is significant, well -- if you can restructure the code in a manner similar to that demonstrated in the article (avoiding costly vtable dispatches, indirection, etc) and achieve a 25x with the original simpler algorithm, then that's something worth taking into consideration. A 3x algorithmic improvement is only impressive if there isn't 25x potential speedup low-hanging fruit (from simply not writing your code in a moronic way in the first place).

[robalni]

Yes. When I worked as a game engine programmer, two of the first things I did were to improve the speed of compiling and starting the games. When those two things are faster, all development will be faster and more fun.