These are more complicated to track down, primarily
because they have many callers (Array#each is used in many places).
The optimization process for this problem was fairly difficult, and we do not show it
here; it was a fairly boring and highly application-specific optimization. (It involved
rewriting a complicated clustering algorithm to build up the same data set using
fewer intermediate data structures.) But the change did result in a small improvement
in the profile, as well as the overall running time:
Thread ID: 2057980
Total: 10.7
%self total self wait child calls name
7.94 1.38 0.85 0.00 0.53 4430 Array#each_index
5.23 1.77 0.56 0.00 1.21 4230 Array#each-1
Rails Optimization Example | 161
3.64 0.40 0.39 0.00 0.01 133960 Hash#[]=
3.55 0.70 0.38 0.00 0.32 1040 GeoRuby::SimpleFeatures::
HexEWKBParser#decode_hex
Benchmarking
Now that we have made optimizations, we should see how they affect the actual performance
of our application. We saved this section for later so that we could compare
the two optimizations to each other; in reality, you should benchmark after
each optimization to be sure that each change has the desired effect.
We will be comparing the performance of the three versions of the application:
??? No optimization (the control)
??? The Listing#location optimization
??? The rewrite of the clustering algorithm
Source Control and Optimization
Source control is our friend during the optimization process.
Pages:
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250