Donald Knuth said:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
When is that holds to be true? How do I know that I am not wasting my time?
I think what Knuth means is that you should not start optimizing because of a "gut feeling" that some algorithms in the program may run faster. You should first finish the program and then measure the performance. If the performance is sufficient, stop; else identify the problematic parts and optimize only as much as necessary.
Faster code is less readable, and a non-critical perceived problem probably solves itself in one or two processor generations (or your optimization becomes obsolete), so keeping it simple is a very good advice. As Peter implies, the actual most critical parts are often in the most unusual and unexpected places.
So the message is to base the optimization decision on facts (measurements) and not on guessing (programmer intuition).
I think what Knuth means is that you should not start optimizing because of a "gut feeling" that some algorithms in the program may run faster. You should first finish the program and then measure the performance. If the performance is sufficient, stop; else identify the problematic parts and optimize only as much as necessary.
Faster code is less readable, and a non-critical perceived problem probably solves itself in one or two processor generations (or your optimization becomes obsolete), so keeping it simple is a very good advice. As Peter implies, the actual most critical parts are often in the most unusual and unexpected places.
So the message is to base the optimization decision on facts (measurements) and not on guessing (programmer intuition).
I second Matthias here: Dont try to optimize while you write the code.
First, make it so simple that you yourself can understand the code even after some weeks where you didnt touch it. Then, start measuring performance, identify the actual bottlenecks, and start thinking about alternatives - but always with the simple code as a baseline _and_ a fallback (in case you have to deliver the code result already).
That seems reasonable , making optimizations that will target a global impact rather than local ones should be the goal here , that is of course after performing some measurements and some profiling.
Thank you all for your replies, much appreciated.
The answer to the question: "How do I know that I am not wasting my time?" is one of those eternal philosophical questions that has import beyond any single context such as premature code optimization.
1. For many contexts you will only know the answer when you are done, and perhaps not even then.
2. For many other contexts, "do not even begin", is THE one and only proper answer.
3. And, of course, for many OTHER contexts, the answer will be discovered somewhere in the middle, somewhere between 1. and 2.
Now for getting back to "code optimization" - your solution will be bound by, and found in cases 1., 2. or 3.
Next question?
Late to the topic, but related::
http://tagide.com/blog/advice/laws-of-peformant-software/
@Robert , it is never late , thank you for adding this link and for your answer ,
Thank you all for your valuable comments
- Badges
- Science topic
- Similar topics
- Computer Science