BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

New Patches for 1.8.x Fix Memory Leaks And Improve Performance

| by Werner Schuster Follow 4 Followers on Jan 06, 2009. Estimated reading time: 2 minutes |

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?

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT