28 0.28 Array#<<
3.92 0.31 0.02 44 0.45 6.36 Array#each
3.92 0.33 0.02 287 0.07 0.07 Kernel.respond_to?
154 | Chapter 6: Performance
3.92 0.35 0.02 89 0.22 0.45 Array#each_index
3.92 0.37 0.02 89 0.22 0.34 Inflector.humanize
1.96 0.38 0.01 179 0.06 0.06 Kernel.===
1.96 0.39 0.01 67 0.15 0.15 String#concat
1.96 0.40 0.01 16 0.63 0.63 ActionView::Base#
template_exists?
1.96 0.41 0.01 613 0.02 0.02 String#to_s
1.96 0.42 0.01 7 1.43 1.43 MonitorMixin.synchronize
(and many more lines...)
These results include the following columns.
The generated profile shows that we are spending most of our time in five functions:
html_escape (better known as h( )), gsub, compute_public_path, option_value_
selected?, and <<. This is hard to improve upon, and in fact this particular action is
pretty snappy. There is not much that we can do to reduce time spent in methods
like Array#<< except find ways to call them fewer times.
This example demonstrates both the power and weakness of flat profiles. Although
they are very useful to get a general idea of which functions are taking the most time,
they do not help very much with long-running or complicated programs. Rails applications
certainly qualify as complicated??”even a simple action can easily have hundreds
of lines in the profile. It can be difficult to track down where your expensive
functions are being called.
The solution to this complexity is, believe it or not, more complexity??”provided we
introduce some structure to the data.
Pages:
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240