Tutorial

Microseconds Matter
Performance lessons learned from hacking on Merb
By Yehuda Katz

If you want to build an app that’s blistering fast, and This clocks in at around 3 microseconds. The second
easy to extend, you can learn a few things from Merb. approach uses Ruby’s #inject:
In building Merb, we’ve heard a lot of statements like
“What are you smoking? If you picked Ruby you obvi-
ously don’t care about speed!” Sadly, we’ve heard these
things from good Ruby programmers, which makes it
hard to win over people who are peeking their heads
into the Ruby world with misconceptions about what
exactly Ruby’s strengths and weaknesses are.
Why Count Microseconds? People frequently criti-
cize Merb for over-optimizing to the point of caring
about–gasp–microseconds. Let’s take a moment to do
a bit of math. Merb can render approximately 2,000
requests through its critical path. By critical path I
mean the code that takes a request, routes it, instan-
tiates the appropriate controller, calls its action, and
then returns the result.
As framework developers, we count microseconds
because we’re actually dealing at that level. We only
have 500 of them to render a complete request. When
we reduced the time it took to run Merb’s critical path
from 600 microseconds down to 500, we went from
1,650 requests per second to 2,000 requests per sec-
ond. But what does this mean in practice? Let’s take a
look at a simple example:
$55$< ZWKHTXLFNEURZQIR[MXPSHG
over the lazy dog) method(ARRAY).should
== %w(t q b f j o t l d)
Let’s examine three ways to solve this problem. First,
the simple iteration approach:
GHIPHWKRGDUUDUULQMHFW>@^_DFFL_
DFFL>@FKUDFF`HQG
This clocks it at over 4 microseconds. The final ap-
proach uses #injecting, which saves us from hav-
ing to return the accumulator from the inject block:
def method(arr) arr.injecting([])
^_DFFL_DFFL>@FKU`HQG
This clocks in at 6 microseconds. At this point, some-
one usually politely stops and tells me I’m rather in-
sane for caring about 3 microseconds. After all, a mi-
crosecond is a tiny amount of time.
Yet Merb bans #inject in our critical path. We also
ban #returning (which costs around a microsec-
ond per invocation) and Symbol#to_proc (which
costs about 6 microseconds for a single-element Ar-
ray, and an additional microsecond for additional ele-
ments), even though the supposed elegance gains seem
to outweigh the negligible performance losses.
And in fact, there may be no room in your app for
this sort of aggressive number-crunching. However,
contrary to popular belief, Ruby is not so slow as to
negate optimization in the microsecond space. This
means that you need to know your own critical path,
and that it may in fact be true that optimizing a rarely
used action for efficiency over elegance is not the cor-
rect choice. Just keep in mind that those choices are
not as obvious and lopsided as some may have you
GHIPHWKRGDUU[ >@DUUHDFK^_L_[ believe. Now that we’ve covered speed, what about
L>@FKU`[HQG modularity, another Merb hallmark.
24
the
Rubyist
 Ruby is Not an API Because Ruby has powerful
metaprogramming facilities, many Ruby program-
mers, including a large number I’d consider excellent
Ruby programmers, have adopted the Ruby-as-API
programming model. In effect, they expect frame-
works, like Rails and Merb, to consider their entire
codebase to be open to tinkering and modification.
The poster child for this philosophy is Rails’ alias_
method_chain. Specifically, alias_method_
chain makes it possible to take an existing method
and extend it with new functionality. This may seem
elegant, because it provides powerful functionality, but
it has some serious drawbacks.
By sending the message that any method, public or
private, is available for extending via plugins, Rails
has made it nearly impossible to do any significant
refactoring of their growing codebase. Changing even
seemingly-innocuous methods can have a devastating
effect on any number of plugins that have signed on to
the alias_method_chain API approach.
Also, using alias_method_chain as an API
makes it difficult for other developers who wish to ex-
tend methods to know how the methods might already
have been defined, leading to possible conflicts or con-
fusions that are difficult to track down. Stack traces that
involve alias_method_chain can double or triple
in size, making it hard to track down exactly where
the code in question comes from. To demonstrate, the
critical-path stack trace of a Rails app is 17 lines above
Mongrel, including a number of duplicate lines due
to alias_method_chain. The Merb critical-path
trace, by contrast, is just 7 lines above Rack.
So what’s the solution, then, if using Ruby as an API
is verboten? Merb’s approach is to clearly define a lim-
ited public API that is to be used by app developers,
and a slightly more expansive API to be used by plugin
developers. The vast majority of Merb’s methods, how-
ever, are considered private functionality, and extend-
ing those methods is not supported.
But wait just a cotton-picking minute. Who wants
to be programming in Java or C# with “final” classes
and methods? As it turns out, forcing ourselves to pro-
gram to a public API, and forcing our non-essential
modules (merb-more) to follow the same Plugin API
that we expect plugin developers to use has led to ex-
tremely extensible code.
More than a few people have hopped into the Merb
IRC room with an example of a case that seemed to
require the use of alias_method_chain. We don’t in-
clude it with merb-core, and when people learn that
we don’t recommend it, they’re frequently hot and
bothered and want to prove that we’re oh so wrong.
Without exception, these issues can be tracked down
to one of two sources.
The first, more common reason is that the person
missed something in our public API. By recommend-
ing against the use of alias_method_chain, people
come looking for help and are able to learn to use
Merb’s public API as intended instead of overriding
our methods in ways that may not be compatible with
future versions of Merb.
The less common, but much more interesting cause
is that our public API is missing something. In other
words, someone is trying to achieve something with
Merb that cannot be achieved via the public API alone.
And without exception, we have looked at those situ-
ations and figured out how to enhance our public API
to support what they were trying to accomplish.
Spending the time to think through the interface we
are exposing to users of the framework and plugin de-
velopers allows us to keep the number of entry-points
into our system to a minimum, and help ensure that we
can refactor without breaking a lot of existing code.
The simplest take-away from our approach is that
you basically never have to monkey-patch your own
code. If you’re doing this, there is likely an issue with
the inter-class interfaces you have exposed. While it’s
easy to fall into the trap of looking at Ruby’s flexibility
as a license for loose, unclear interfaces, our experience
shows that spending the time to design your interfaces
pays off.
I Still Think You Guys Are Nuts! After reading
this, you might think that our approach works fine
in framework code, but is way too aggressive for app
code. We pretty much agree with that, and almost no-
body on the Merb core team writes our applications
using the aggressive approach we use in Merb’s critical
path. But it’s still worth keeping in mind that Ruby
is not so slow as to make small gains irrelevant, that
Ruby can be made to be fairly fast if it needs to be, and
that well designed interfaces are possible, even though
Ruby-the-language makes them strictly unnecessary.
Yehuda Katz is a core team member
of the Merb and jQuery projects. He
currently works for Engine Yard as a
Merb developer.
http://www.yehudakatz.com/