147Chapter 6 CHAPTER 6
Performance 6
Premature optimization is the root of all evil (or at
least most of it) in programming.
—Donald Knuth (attributed to C. A. R. Hoare)Performance is an interesting beast. Performance optimization often has a bad repu-
tation because it is often performed too early and too often, usually at the expense of
readability, maintainability, and even correctness. Rails is generally fast enough, but
it is possible to make it slow if you are not careful.
You should keep the following guidelines in mind when optimizing performance:
Algorithmic improvements always beat code tweaks
It is very tempting to try to squeeze every last bit of speed out of a piece of code,
but often you can miss the bigger picture. No amount of C or assembly tweak-
ing will make bubblesort faster than quicksort. Start your optimization from the
top down.
As a general rule, maintainability beats performance
Your code should be first easy to read and understand, and only then optimized
for speed.
Only optimize what matters
Typically, the code profile has a lopsided distribution: 80% of the time is spent
in 20% of the code (for some value of 80% and 20%). It makes sense to spend
your limited resources optimizing the sections that will bring the greatest gain in
performance.
Measure twice, cut once
The only way to be certain about where your code is spending its time is to mea-
sure it. And just as in carpentry, you can waste a lot of time if you make changes
without being very sure exactly what those changes should be. In this chapter, we
will explore some of the best tools and methods for determining where to cut.