leonardoborges.com

the not so usual geek stuff…

This post is just to clarify some confusion I’ve noticed reading some posts around the web. There is some misunderstanding of the differences between Ruby 1.8 and Ruby 1.9 regarding threads. And the difference between them and JRuby.

So I decided to write this small summary:

Ruby 1.8 - Supports only Green Threads

This means that the ruby interpreter has its own scheduler. No matter how many threads you create in your ruby program, there will be only one native thread on your OS. Therefore, your program cannot take advantage of multiple core environments.

Ruby 1.9 - Supports native threads (GIL)

Ruby 1.9 adopted YARV as the new VM implementation, which supports native threads. This means that now your ruby programs can take advantage of multiple core environments, but no truly parallel execution is achieved.

The catch is GIL - Global Interpreter Lock - and it means that each ruby thread runs on its own native thread, but only one of them can be executed at a time.

JRuby - Ruby 1.8 compatible

I think this is the easy part. JRuby runs on the Java VM, which supports native threads and parallel execution.

On this environment, ruby threads are java threads.

The future

There doesn’t seem to be any decision about what’s gonna happen on the next versions of Ruby. At least to the extent of my research. But this is today’s snapshot of Ruby threads and I hope it’ll be useful to some folks.

c u around

REXML is the standard XML processing library for Ruby. It’s on Ruby’s core and is terribly slow.

Yeah, I know it’s pretty simple to use, got a nice interface and, again, it’s just there. And it is a good library, for most things. But if you, as me, came to a point that processing XML is taking 50% of the time to render a rails action, it’s time to change.

My tip? Use libxml instead. The numbers on their home page speak for themselves. Try it yourself, you won’t be disappointed. And I’m really happy with the performance increase on our app.