Optimizing Code for Speed/Conclusion

When I mentioned this article to some people on IRC (while it was still incomplete), someone said that "The first rule of optimization is 'Don't!'". I think such attitude is harmful. While I agree that "premature optimization is the root of all evil", sometimes one's code is just too slow and needs to be optimized. And if your code is what Joel Spolsky calls "Shrinkwrap" (i.e: code that is sold or otherwise distributed and made available for public consumption) then you can often not make assumptions on how fast it needs to be, and the faster it is - the better.

Speed and optimizing other resources are one important factor in the general, abstract quality of programs. If your program is slow, it is likely going to make your users frustrated and unhappy, which will be a failure in your mission as a software developer. So it is important that your program is fast enough, if not very much so.

My aim in this document was to explain the "why"'s, "what"'s and to a lesser extent "how"'s of optimization. I hope I was successful, and that people who read it will be more willing to optimize their software and more clueful in how to do so.

Further ReadingEdit

Jon Bentley discussed various kinds of optimisations extensively in the book Programming Pearls 2nd Edition ISBN 0-201-65788-0. which is a very recommended read. He also recommends there his out-of-print book Writing Efficient Programs ISBN 0-13-970244-X for more discussion on the subject. There's also a lot of discussion on optimisation in the book The Algorithm Design Manual, 2nd Edition ISBN 978-1848000698.

The paper "Why Userspace Sucks" by Dave Jones details some bad practices in the GNU/Linux userland applications that hurt performance. Steve Souders gave an amusing talk titled "The Illusion of Speed". A blog post titled “Premature optimization is the root of all evil” is the root of evil also gives some insights.

Finally note that in 2018, I wrote a summary for an essay about "reflections how software quality has improved or worsened".

ThanksEdit

I'd like to thank Daan for expressing a lot of interest in this article, and for his constant encouragement and input. Limbic_Region has given me some useful input for this article by email. Several people have made some contributions to this article: Jguk, Dallas1278 and the IPs 84.27.42.81, 85.146.243.13, 203.196.46.108, 70.176.53.73, and 213.129.10.120 . I'd also like to thank all the originators of the sources that I quoted or referenced in the article.

External LinksEdit