The Need for Speed

It’s a widely shared belief that Ruby is slooow. Ruby, the common wisdom says, is a lovely language that saves you time while you’re developing your application but drags its feet when you execute it. How much truth is there to that belief?

Well, good old Ruby 1.8, released in 2003, was indeed slow. But since then Ruby developers have radically improved the language’s performance. Ruby 1.9 added a virtual machine that executes the code faster. Ruby 2.0 has copy-on-write friendly memory management that makes large web application deployments faster. And finally, thanks to the outstanding work of Koichi Sasada, Ruby got a generational garbage collector in version 2.1 and an incremental garbage collector in 2.2. That work continues and better performance is now one of the primary goals of the new releases.

So how slow is Ruby now? Not so slow: it’s now on par with other dynamic languages. And how slow are Ruby applications now? Ah, that depends. A lot of legacy code exists that still runs Ruby 1.8 or 1.9 with little to no possibility to upgrade. You can assume that it’s slow. But more importantly, there is a whole lot of Ruby code that was written without performance in mind. And that code will stay slow no matter which Ruby version you run.

I have been developing Ruby and Rails applications since 2006. I have seen slow Ruby code everywhere. And now in 2015 I still have to spend as much time optimizing my code as I did back in 2006—even when I use the latest and fastest Ruby.

You might very well be wondering why I bother to optimize code when there are other, better-known ways to make an application run faster—namely caching and scaling. Both techniques are well known and understood. You’ll have no trouble finding plenty of advice on caching strategies, as well as many scaling recipes, and some very good tools are available for caching and scaling.

And you’re right, caching and scaling do help with performance. I used to do both. But one day my cache invalidation code became too complex. Another day I found myself spending too much money on servers and Heroku dynos. Then there was the time when my long-running asynchronous processes ran around the clock and still struggled to serve incoming jobs in time. That was the point at which I started looking at code optimization. I wanted to make my programs run faster and use fewer resources. It turned out code optimization is the only way to do that more cheaply and without overcomplicating the application architecture.

To my surprise I found no good single source of information on Ruby code optimization. Resources you can find online are either technical descriptions of Ruby internals or advice on micro-optimizations like the recommendation to use instance variables instead of method calls. But knowledge of the internals is not useful without an understanding of the big picture. Micro-optimizations sometimes work, but most times they’re simply too low-level to be effective.

I learned code optimization myself the hard way and wrote this book so you don’t have to tread that hard path. In this book you’ll learn why Ruby code becomes slow, how to make it faster, and what tools to use to do it. I hope you’ll also grow to enjoy code optimization as much as I do. It is a very rewarding process: you dig the details, you build the big picture in your mind, make a change, and measure a difference. And you instantly know how big/important your change is. This is the second shortest reward cycle I know after writing “Hello World” in a new language.