Why you should probably not bother about Ruby’s speed

The expressivity and power of Ruby make it a really efficient programming language. Its dynamic nature results in lots of enjoyable benefits (introspection, dynamic class reopening…); it is also responsible for a part of its performances, which are sometimes believed to be poor.

Is Ruby really slow? While being obviously slower than most natively compiled languages, is the performance gap really worth noticing and should it prevent you from using this great language?

If all you’re coming for is pure performance benchmarks, you may directly skip to the last part of this article (“Lies, damned lies, and benchmarks”), since this article does not aim at benchmarking Ruby.

ruby –version

Depending on your OS or the way you installed Ruby on your computer, you may be facing two different major releases of Ruby. If you take a look at Ruby’s history, you can notice that the 1.8.x branch started in 2003 and was joined by the 1.9.x branch at the very beggining of 2009. Since then, these two versions are coexisting, while being different in a number of ways.

The most interesting change is related to the interpreter itself: YARV, the mainstream Ruby 1.9.x interpreter, is now dealing with bytecode, rather than constantly parsing and executing unoptimized Ruby code. The addition of a few other optimizations induced a great speed boost for most Ruby scripts (about three times faster on average, according to benchmarks which are legion on the Web: for example, here and here).

Sadly, most beliefs about Ruby are based on the old 1.8.x branch, which was the most used branch until now, but tends to be replaced by newer versions; a great effort is being made to migrate major gems (Ruby packages, such as Rails) and applications to the 1.9.x branch. The new Ruby interpreter comes with a revision of the language itself, which makes this migration not as easy as it seems and explains why some people are still late to the party.

One language to rule them all, and in the runtime bind them

Aside from the well known MRI and YARV, which are respectively shipped with Ruby 1.8.x and Ruby 1.9.x, some other mature Ruby interpreters are available and quite widely used. They feature some additional or structural refinements, which make them better suited than the mainstream interpreters in some situations. Two of the most notable challengers are:

• JRuby: an interpreter based on the Java Virtual Machine, providing an easy integration with Java libraries as well as the obvious advantages of running inside the JVM;
• Rubinius: an interpreter written in C++, which features Just-in-time (JIT) native machine code compilation.

These interpreters outperform the standard interpreters for some specific problematics (one of them being parallelism efficiency, which will be the main topic of an upcoming article) and may be worth benchmarking when performances become a concern, before deciding to drop Ruby.

C for hostpots, Ruby for everything else

Most of the standard Ruby library, as well as a number of gems (Ruby packages), is written in pure C. Indeed, Ruby features easy interactions with C and C++: you can use the Ruby API in your C code and your Ruby code can, in turn, easily retrieve results from your C code. This is roughly achieved by using one or more C files, a file composed of a few lines of Makefile-like syntax which will build a library for you, a function call and… that’s it!^[1]

Knowing that, it would be wise to reconsider Pareto’s principle: most of the time, 20 % of your code is responsible for 80 % of your application’s runtime. Rewriting these slow parts in a compiled language like C, while keeping structural parts human-readable by using a high-level language should be the way to go, when possible (i.e. most of the time); that is exactly the Ruby way of thinking. Moreover, when profiling your applications, you will often notice that the slow parts of your application are completely independent from the language you’re using.

And believe me: most of the time, you won’t even need C at all! I have myself never really needed to rewrite parts of my applications in C, even when raw performances were a vital concern. In fact, the only time I really thought I needed it led me to a complete waste of time, since I was trying to improve performances by focusing on the wrong problem. This is not to say “never use C” but rather “use C when all other reasonable options failed”; mixing code may reduce your source code readability and maintainability.

Lies, damned lies, and benchmarks

If you expected benchmarks in this article, you will be disappointed. The only general truth that should come to your mind is the following ranking^[2] (sorted by decreasing performance):

• Natively compiled languages (C, C++, Fortran, Pascal…)
• Byte-compiled languages (Ruby 1.9.x, Python, Java…)
• Interpreted languages (PHP, Shell-scripting languages, Ruby 1.8.x…)

Everything else is usually a waste of time for general applications, especially when you are allowed to mix compiled chunks of code in your Ruby or Python application. Keep in mind that the time you save by using a more powerful (in terms of expressivity, readability, standard structures…) language can be used to throw up some heavy algorithmic as well as parallelization optimizations, which will make a greater difference, most of the time.

Well, if you really want benchmarks (because I know you’ll be upset otherwise), you may want to follow this link (but I warned you!).

Conclusion

I hope this article convinced you that considering Ruby as a slow language is mostly false and generally irrelevant. For those of you who need extreme performances, a natively compiled language like C or C++ will certainly perform better in some cases.

But if you don’t fit in this category and, nevertheless, plan to drop Ruby^[3] just because you think it won’t be fast enough for you, you may want to reconsider your thoughts…

---

1. This will be discussed more thoroughly in an upcoming article about Ruby and parallelism.
2. Languages are categorized with respect to their current main implementation (eg. MRI for Ruby 1.8, YARV for Ruby 1.9…).
3. The same reasoning applies to Python as well.