No amount of C or assembly tweaking
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 measure
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.
148 | Chapter 6: Performance
Measurement Tools
Of course, in order to properly measure performance, we need tools. This section is
concerned with analysis of Ruby and Rails code, as well as web applications in general.
There are a series of tools that can be used to analyze the full Rails stack, from
HTTP down to Ruby??™s internals.
Black-Box Analysis
The most basic high-level measurement you will be interested in is: in the ideal case,
how fast can this server serve requests? While the answer is a somewhat nebulous
value that often bears no relation to actual performance under typical load, it is still
useful to compare against itself??”for example, when testing caching or deploying a
new feature set.
Pages:
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231