The Art of

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil”

–Donald Knuth

 

If you’ve heard of Big-O analysis, or linked lists, or sorting, or searching, or recursion, or pretty much any other thing you as a programmer would know, chances are Donald Knuth was writing about it first in his 1968 book The Art of Computer Programming. The quote above is one of my favorites, and there’s a lot of insight in it.

Put another way, Knuth is reminding us that “over-optimization” from the start leads to unnecessary headaches further down the road, and can even cause projects to end up unfinished and late. Here’s just a few of the dangers that extensive optimization early in a project can lead to down the road:

  • Danger in Completing the Program
    Say you’re creating a physics engine for your game, and need to do a matrix calculation. You could do this the straightforward way, but you decide that CPU operations are too slow. So you write a GPU accelerated matrix library because normal CPU based matrix calculations are slower. After a few weeks muddling around with OpenCL in your side library, your physics engine will be late, or you could have lost the motivation to even finish it.The icing on the cake here is that you don’t even know that your matrix calculations would be a bottleneck in your engine! It could be that the derivatives calculation is really what slows you down to an unacceptable level. By optimizing too early, you optimized something didn’t really need it, and wasted a bunch of time doing so.But hey, at least you’ll have a decent GPU accelerated matrix calculator!
  • Danger in Legibility/Understandability
    It could be faster to unroll loops and make full use of the SSE extension through x86 assembly for some areas of your code. This doesn’t make it easier to understand, and surely obfuscates the meaning of what you’re trying to do! In some circumstances this can’t be avoided, but if you optimize later in the development, you’ll only have your assembly code in limited areas where you really do need it.
  • Danger in Maintenance
    If you have some highly optimized chunks of code, they can be more difficult to adapt to any new changing circumstances, simply because there might only be 1 or 2 people who understand what is going on! If you don’t get what’s going on, changing a nonintuitive optimized chunk of code might introduce corner cases that show up later on as bugs, crashes, or worse. Like with legibility, you want these chunks of code only where you absolutely need them. Optimizing later in the development process will ensure that your complex, hard-to-grasp code is just where you need it to be, and will help out anyone who might have to maintain things later down the road.

Being able to know what to optimize is just as important as deciding what features your project should support. Both are also learned over time; they’re a wisdom that comes with experience (or good project management!)

This entry was posted in Coding, Open Source. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *