Specifications

This means there were 608,720 calls to
Buffer#read during the test, which took a total
of 38.13 seconds, or 13.75% of the execution
time. Because this is a built-in method, you can’t
optimize it. However, you can try to reduce the
number of times it is called, so that it will take
even less time.
The question is, how do we know which func-
tions are calling Buffer#read? Perhaps reading from
buffers is an inevitable part of a Web application,
and we just need to realize that?
If you look at the second file, profile-graph.html,
you see a nicely linked description of which
methods called which other methods, and how
long it took. Each box represents the analysis of
one method, and the method being analyzed is
printed in bold.
All of the methods above the boldfaced
method name are parent methods (that is,
methods that called the one in question);
whereas, methods below the current one are
child methods (that is, methods that are called
by the method being analyzed). By looking at
who called Buffer#read, you can see which
methods (if any) need optimizing or a smaller
number of invocations. By going back and
forth between methods, their parents and
the source code, you can cut down on a great
deal of waste, making your sites more efficient
than before.
Conclusion
This month, we looked at two basic profiling
tools that programmers can use to identify per-
formance problems in Rails-based Web sites.
There are, of course, other tools we can use, but
the fact that these are so nicely integrated into
Rails makes us all the more likely to use them.
With constant monitoring and tweaking, we can
make our sites run faster without having to
resort to buying additional servers.
I
Reuven M. Lerner, a longtime Web/database developer and consultant, is a PhD
candidate in learning sciences at Northwestern University, studying on-line
learning communities. He recently returned (with his wife and three children) to
their home in Modi’in, Israel, after four years in the Chicago area.