Ruby 1.9.1 and JRuby currently lead the pack of Ruby implementations when it comes to performance. However, for various reasons, switching to either of these Ruby implementations might not be possible just yet, as Ruby 1.9.x breaks compatibility with 1.8.7 in some areas and JRuby still lacks some Ruby libs that use native extensions. With that in mind, MRI 1.8.x seems here to stay for the near future, so there's interest in improving its perfomance.
Brent Roman now brings a few performance improvements to Ruby 1.8.x MRI. He started out trying to fix memory leaks in Ruby, particularly in continuations:
The basic technique is a refinement of the one Kurt Stephens suggested. It not only eliminates the leaks in this one liner:
loop {@x=callcc{|c|c}}
but also in our multi-threaded robotics application. Our Ruby process used to grow to 20+ MB during a day long run. The same run now stays smaller than 10MB.
As it turns out, the leaks are caused by GCC optimizations that interact badly with Ruby's conservative GC:
The garbage collector's leaking memory is not really its own fault. The trouble is that the 'C' machine stack is filled with object references. The main reason for this is that gcc compilers create overly large stack frames and do not initialize many values in them. Certain 'C' constructs used in the Ruby interpreter's core recursive expression evaluator generate especially large, sparse stack frames. The function rb_eval() is the worst offender, creating kilobyte sized stack frames for each invocation of a function that may call itself hundreds of times. This results in stacks that are hundreds of kilobytes, often full of old, dead object references that may never go away.
Brent has provided a few patches (against Ruby 1.8.7-patlevel72 which aim to fix these problems.
Testers report significant speedups with the patches while running real world Rails apps. A few issues were reported as well, so it remains to be seen where this goes.
These patches are another example of the open source (Ruby) community improving MRI. Mod_rails (or REE) is another example, which made MRI's Garbage Collector fork-friendly (see the linked news item for an explanation).
MRI's performance can also vary significantly depending on how it was compiled.
Are you planning on sticking with Ruby 1.8.x in 2009? If yes, what are the main reasons?