In the introductory classes for the optimization course, the students and I discuss a question like “When should you start optimizing?” You can often hear the answer attributed to Donald Knuth: “Premature optimization is the root of all evil.”
Usually, this phrase (actually taken out of context) is interpreted this way: you must not start optimizing a program until it has been written and tested. The motivation here is as follows: a) until development is complete, it is impossible to assess the performance of the entire system as a whole; b) optimizations can lead to unreadable code, which is also very hard to debug. These statements are accepted as dogma, despite the fact that certain lines of reasoning led the author to this phrase, and without them the quote itself is meaningless.
Let’s go back to the original sources. The quote in question can be found in the article: Knuth, D. E. 1974. Structured Programming with go to Statements. ACM Comput. Surv. 6, 4 (Dec. 1974), 261-301.
In the original publication, Knuth talked about programmers spending a great deal of time thinking about the performance of noncritical pieces of code, where attempts to optimize them have a negative effect on the program as a whole. In his view, one should not pay attention to the little things, but should focus specifically on the critical places, and only after those places have been precisely identified. Here I agree with the author completely.
I defend the point of view that program optimization is a set of planned actions that receive due attention during the development of the entire system. Performance testing should be carried out on par with functional testing, with respect to the system’s performance requirements. Obviously, for a broad class of applications, a discovered performance problem has a higher priority than the main development tasks: computer games, audio/video codecs, control systems for critical facilities. Fixing a performance problem is exactly the optimization that is done on time, long before the program’s development is finished. Fixing such problems in a timely way reduces project risks. And conversely: problems left for “later” lead only to missed project deadlines and failure to meet performance requirements.
The following recommendations can be formulated:
-
define performance requirements (for example, how many frames per second a game should display, or how long processing a file should take);
-
develop performance tests with respect to the stated requirements (they can be done as part of unit testing);
-
test performance on par with functional testing;
-
when problems are found, focus only on those pieces of code that will yield the maximum gain.
And in general, judging by the abstract, the article is about how to get rid of the go to statement. Naturally, students in the SCS specialty can freely familiarize themselves with this article by contacting me by email. :)