Programming: Premature optimization is the root of all evil?
There is something about the phrase "Premature optimization is the root of all evil" that gets in my crow. Perhaps it's because I like doing optimization, or perhaps because I've seen code go into production that is embarrassingly slow. [BTW, the full quote by Hoare and Knuth is: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.", I have less issues with the full quote]
There's another expression that's similar in the Agile world which is "Ain't gonna need it". Basically, don't put in code unless you need it right now to fulfill your tests. There's a tendency for programmers to put in code because they think they'll need it sometime in the future. When it finally does get used, a year later, it doesn't work because it was never tested.
The evil here is over-engineering the code. I've seen junior (and not so junior) developers create code which I thought was way too complicated for the job at hand. They develop a whole family of inherited classes were created where maybe one class would have been simpler. I think the premature optimization bit has the same feel but in my experience is less of a problem than over designing the code.
Now back to premature optimization. I think what they really want to say is that "Unnecessary optimization makes code that is unmanageable, buggy and late" and there's more:
Well that's the theory. And here's some of my counter arguments:
Well this rant is getting a little long. Basically, you can get into trouble if you think things are black and white (think of Bush). Things are complicated and many shades of gray. So to with optimization. You need to have a good feel for how all the code hangs together and what the machine is really doing. This is hard and takes experience. How many developers really understand how Oracle runs a query, or how memory is allocated and freed in Java, say.
As long as you keep running the code in your head and satisfy yourself that either the code is fast enough or that there's no other clean or easy way of making it faster if you're not sure then you should be alright. The balance is between maintainability, correctness and performance.
The mistake is to blithely code along ignoring performance until it's too late and you have egg over your face and it looks like a major rewrite is in the works (by someone else, because you've been fired).
Links:
There's another expression that's similar in the Agile world which is "Ain't gonna need it". Basically, don't put in code unless you need it right now to fulfill your tests. There's a tendency for programmers to put in code because they think they'll need it sometime in the future. When it finally does get used, a year later, it doesn't work because it was never tested.
The evil here is over-engineering the code. I've seen junior (and not so junior) developers create code which I thought was way too complicated for the job at hand. They develop a whole family of inherited classes were created where maybe one class would have been simpler. I think the premature optimization bit has the same feel but in my experience is less of a problem than over designing the code.
Now back to premature optimization. I think what they really want to say is that "Unnecessary optimization makes code that is unmanageable, buggy and late" and there's more:
- When a program has performance problems the programmer always knows which part of the code is slow...and is always wrong.
- Only through profiling do you really see where the performance issue is.
- You can waste a lot of time doing optimization that doesn't matter.
- Optimization can often make the code more obscure, and hard to maintain.
- Spending more time on optimization means you are spending less time on other things (like correctness and testing).
Well that's the theory. And here's some of my counter arguments:
- If a developer really enjoys what he is doing it wont take any "extra" time. In other words, taking time to optimize doesn't necessarily steal time from testing, more likely it steals time from surfing the web
- Every time a developer looks at the code for something to optimize, he's looking at the code! He understands (groks) it better and may fix more bugs.
- Encouraging developers to leave in code that they know is embarrassingly slow makes them a little less proud of their code, a little less enthusiastic about finding and fixing their bugs.
- Products have failed because in a review they mention that it took twice as long to load a document than the competitor (even though it was 2 seconds instead of 1)
- When you put the code in production and it's too slow, you may be able to fix it by profiling and optimizing, but then again, you may not - you may have to redesign it.
Well this rant is getting a little long. Basically, you can get into trouble if you think things are black and white (think of Bush). Things are complicated and many shades of gray. So to with optimization. You need to have a good feel for how all the code hangs together and what the machine is really doing. This is hard and takes experience. How many developers really understand how Oracle runs a query, or how memory is allocated and freed in Java, say.
As long as you keep running the code in your head and satisfy yourself that either the code is fast enough or that there's no other clean or easy way of making it faster if you're not sure then you should be alright. The balance is between maintainability, correctness and performance.
The mistake is to blithely code along ignoring performance until it's too late and you have egg over your face and it looks like a major rewrite is in the works (by someone else, because you've been fired).
Links:
Comments