The fallacy of premature optimization
Randall Hyde · Ubiquity · 2006
Every programmer with a few years' experience or education has heard the phrase "premature optimization is the root of all evil."This famous quote by Sir Tony Hoare (popularized by Donald Knuth) has become a best practice among software engineers.Unfortunately, as with many ideas that grow to legendary status, the original meaning of this statement has been all but lost and today's software engineers apply this saying differently from its original intent.As computer systems increased in performance from MHz, to hundreds of MHz, to GHz, the performance of computer software has taken a back seat to other concerns.Today, it is not at all uncommon for software engineers to extend this maxim to "you should never optimize your code!" Funny, you don't hear too many computer application users making such statements.It is unfortunate that Hoare's comments have been twisted to imply that optimization is unnecessary.The bloat and unresponsiveness found in many modern applications compels software engineers to reconsider how they apply Hoare's comments to their projects.As you can probably tell, this article is not "yet another article warning beginning programmers to avoid premature optimization."The purpose of this article is to examine how software engineers have (incorrectly) applied Hoare's statement as a way of avoiding the effort necessary to produce a well-performing application.Hopefully, this article can encourage many software engineers to change their views on application performance."Premature optimization is the root of all evil" has long been the rallying cry by software engineers to avoid any thought of application performance until the very end of the software development cycle (at which point the optimization phase is typically ignored for economic/time-to-market reasons).However, Hoare was not saying, "concern about application performance during the early stages of an application's development is evil."He specifically said premature optimization; and optimization meant something considerably different back in the days when he made that statement.Back then, "optimization" often consisted of activities such as counting cycles and instructions in assembly language code.This is not the type of coding you want to do during initial program design, when the code base is rather fluid.So Hoare's comments were on the mark.Indeed, a short essay by Charles Cook (http://www.cookcomputing.com/blog/archives/000084.html), part of which I've reproduced below, describes the problem with reading too much into Hoare's statement: I've always thought this quote has all too often led software designers into serious mistakes because it has been applied to a different problem domain to what was