Randall Hyde - Write Great Code, Volume 2: Thinking Low-Level, Writing High-Level

There are many aspects of great codefar too many to describe properly in a single book. Therefore, this second volume of the Write Great Code series concentrates on one important part of great code: performance. As computer systems have 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 exclaim, You should never optimize your code! Funny, you dont hear too many computer application users making such statements.

Although this book describes how to write efficient code, it is not a book about optimization. Optimization is a phase near the end of the software development cycle in which software engineers determine why their code does not meet performance specifications and then massage the code to achieve those specifications. But unfortunately, if no thought is put into the performance of the application until the optimization phase, its unlikely that optimization will prove practical. The time to ensure that an application has reasonable performance characteristics is at the beginning, during the design and implementation phases. Optimization can fine-tune the performance of a system, but it can rarely deliver a miracle.

Although the quote is often attributed to Donald Knuth, who popularized it, it was Tony Hoare who originally said, Premature optimization is the root of all evil. This statement has long been the rallying cry of software engineers who avoid any thought of application performance until the very end of the software-development cycleat which point the optimization phase is typically ignored for economic or time-to-market reasons. However, Hoare did not say, Concern about application performance during the early stages of an applications development is the root of all evil. He specifically said premature optimization , which, back then, meant counting cycles and instructions in assembly language codenot the type of coding you want to do during initial program design, when the code base is rather fluid. So, Hoares comments were on the mark. The following excerpt from a short essay by Charles Cook (www.cookcomputing.com/blog/archives/000084.html) describes the problem with reading too much into this statement:

Ive 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 intended.

The full version of the quote is We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. and I agree with this. Its usually not worth spending a lot of time micro-optimizing code before its obvious where the performance bottlenecks are. But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems. An inexperienced developer will not bother, misguidedly believing that a bit of fine tuning at a later stage will fix any problems.

Hoare was really saying that software engineers should worry about other issues, like good algorithm design and good implementations of those algorithms, before they worry about traditional optimizations, like how many CPU cycles a particular statement requires for execution.

Although you could certainly apply many of this books concepts during an optimization phase, most of the techniques here really need to be done during initial coding. If you put them off until you reach code complete, its unlikely they will ever find their way into your software. Its just too much work to implement these ideas after the fact.

This book will teach you how to choose appropriate high-level language (HLL) statements that translate into efficient machine code with a modern optimizing compiler. With most HLLs, using different statements provides many ways to achieve a given result; and, at the machine level, some of these ways are naturally more efficient than others. Though there may be a very good reason for choosing a less-efficient statement sequence over a more efficient one (e.g., for readability purposes), the truth is that most software engineers have no idea about the runtime costs of HLL statements. Without such knowledge, they are unable to make an educated choice concerning statement selection. The goal of this book is to change that.

An experienced software engineer may argue that the implementation of these individual techniques produces only minor improvements in performance. In some cases, this evaluation is correct; but we must keep in mind that these minor effects accumulate. While one can certainly abuse the techniques this book suggests, producing less readable and less maintainable code, it only makes sense that, when presented with two otherwise equivalent code sequences (from a system design point of view), you should choose the more efficient one. Unfortunately, many of todays software engineers dont know which of two implementations actually produces the more efficient code.

Though you dont need to be an expert assembly language programmer in order to write efficient code, if youre going to study compiler output (as you will do in this book), youll need at least a reading knowledge of it. provide a quick primer for 80x86 and PowerPC assembly language.