Spending time optimizing code before it’s finished is called “premature optimization”. This is a sandtrap that many new programmers fall into.
Premature optimizations by new programmers frequently turn out to be pessimizations … they decrease the performance of the code or destabilize it so that it no longer works quite right. Even if a premature optimization works correctly, keep in mind that most optimizations will tend to make the code less maintainable and more difficult to understand, modify, and debug. If you optimize before you’re done, you’re going to make it more difficult to finish.
In general, optimizations are best applied after you have an entire working program, so that you can find where the “hot spots” are, the things which are actually noticeably slowing down your performance. Unless you know where the hot spots are going to be, you can spend days and days making Z faster, only to find that Z is barely noticeable in your program’s performance.
Apple has provided many handy tools to help you find out where to optimize. One of the most useful is /Developer/Applications/Sampler.app. You can see the whole list at: http://developer.apple.com/tools/performance/
A few do’s and don’t’s:
DON’T worry too much about allocation of a few hundred normal objects. An NSString is cheap to create.
– **from where do you have the scoop on NSArray? and wouldn’t this mean less than O(1) access times for arrays? ** – From reading the CFArray source in Darwin, which NSArray uses. And yes it does, but only for very large arrays. At fewer than 64K items, it uses a deque with O(1) access times. It’s interesting reading if you can get over the ugly spacing and lack of comments!
In Donald Knuth’s book Literate Programming, he writes: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”
And as William A. Wulf wrote in his famous 1972 paper, “A case against the GOTO”: “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.”
My fortune output today:
* The First Rule of Program Optimization: Don’t do it.
The Second Rule of Program Optimization (for experts only!): Don’t do it yet. – Michael Jackson *
I have to say that I disagree with this. It should be a standard part of the development cycle to profile a program and attempt to find sensible ways to reduce it’s CPU load and memory footprint. Just because you think your program is well behaved doesn’t mean that a user with limited system resources and a need to run other programs at the same time would agree with you. The exception is when you know exactly what sort of machine will be running your product, and in what environment.
Since the primary form of good optimization is to find better algorithms, I think one should be optimistic that there is always a good chance of getting a big return on a small investment in complexity. But I’m not advocating premature optimization. Just profiling and identifying relatively egregious waste, as in when one small portion of code is eating a disproportionately large amount of resources. It’s up to you to define “disproportionate”, and therein lies the weakness in this philosophy, but if you can reduce your system resource usage by fifty percent or thereabouts, it might make your program more popular. Set hard limits on what is a worthwhile optimization, in terms of the tradeoffs. � BrentGulanowski
I don’t think “Don’t do it” means “Don’t optimize.” But rather, “Find something in your program that you can avoid doing.” Like, rather than look for a cheaper algorithm, look for a way to avoid parts of the work altogether and still get the same result.
In that sense, “Don’t do it yet” would refer to lazy algorithms.
How do you know if the optimization is premature?
Please add to this list.
In some cases, a good alternative to PrematureOptimization is abstracting out the area which you may need to OptimizeLater (applying OnceAndOnlyOnce); therefore, the cost of optimizing will not increase further along in development - allowing you to just as easily OptimizeLater when/if it becomes necessary.
“They spent the whole week optimizing it. It still doesn’t work, but now it doesn’t work a few milliseconds faster.” (from http://www.adaptiveview.com/news.html )