RailsConf is over and it's about time for reflections now. Two hot topics this year dominated the conference - we've got a strong presence from people working on alternative Ruby implementations and lots of presentations on scaling and performance. In short, my two conclusion on those topics are:
- one and only one MRI alternative now really works
- Rails community focuses on scaling rather than performance
Read on and I'll tell you what works and what to do if you want faster and not larger Rails.
Alternative Ruby
The current situation with alternative ruby implementations reminds me of the lions pride. The lion king (read MRI) is old and weak, but it's still strong enough to outperform the subadults. Despite that, some of the youngsters look promising, some them look cool and some look as undecidable. My personal opinion here is that promising implementations take existing VM and implement Ruby on top of them, cool implementation do all on their own and undecidable ones are not open source. Ok, enough generalizations, this topic deserves somebody to talk in details, so here are my stories on JRuby, Rubinius, Ruby 1.9, Iron Ruby and MagLev.
JRuby Story
I've been watching JRuby since its inception. I remember listening to Charles Nutter back in 2006 at RailsConf Europe when he demonstrated the first JRuby version that could run Rails. Cool, I said to myself and continued with MRI.
I also remember myself sitting at Charles' tutorial last year trying to get my application running under JRuby. At that time I spent 3 hours to get the app almost running - all Acunote functionality eventually worked except for burndowns because of broken RMagick. And of course our performance benchmarks showed the application became 3-5 times slower.
This year was a breakthrough. I was sitting through one of the presentations about scaling Rails when I thought that it's a good idea to try JRuby once again. So I did. In 15 minutes I got all JRuby stuff and required dependencies installed and Acunote running. That was a real "wow starts now" moment :) All code we have just worked. Ok, what's about the performance you might ask. I ran Acunote benchmarks and it turned out that JRuby shows exactly the same performance as MRI! And that's using old Java5 Client VM, postgres-pr driver written in Ruby and only 3 requests to warm up the VM. Once I'll get back home, I'll try using JDBC driver, recent JVM and issue more requests for benchmarking. The gut feeling is that JRuby will be faster in that case, watch for my next blog post if you're curious ;)
Rubinius and Ruby 1.9 Story
These guys have all the fun for sure, but they will simply need more time to implement their VM's right. As you see from my previous story, three years was enough to get JRuby really working. And bear in mind, they didn't have to write VM.
Despite that, I personally become more and more interested in Rubinius. As you might know, I'm KDevelop IDE developer and one of the guys who worked on Ruby support for KDevelop. Java support in Eclipse is so cool just for one reason - they have compiler built in that knows everything about your code. Rubinius looks like a perfect tool to do exactly this for KDevelop. It may be able to load all the code and keep it constantly running as you work on the project and IDE would be able to recompile changed bits of the code on the fly. This Smalltalk-like way is probably the only way IDE can know about all symbols in the code written in dynamic language. I'm definitely looking forward having some free time to play with that.
MagLev and IronRuby Story
MagLev today is even less than JRuby in 2006. It's still more like a proof-of-concept that you can run Ruby on Smalltalk VM rather than a product in development. It was quite cool to see Smalltalk-like object caches and stores working with Ruby. As somebody said, seeing two irb's working with the same global state was a mind-blowing experience :)
Anyway, during the next 3-4 years we'll see whether they survive and produce something useful. The only issue in my opinion with MagLev is that it is closed source. These days you have to have really really good product to compete with open source in the arena of languages, compilers and VM's. Time will tell whether MagLev will have that advantage.
Microsoft's IronRuby is slightly more mature (maybe because it runs Rails ;)) but still has a long way to go. IronRuby guys also did have some cool stuff to show us at their presentation. Their mind-blowing thing was the same Ruby application running on server (Rails app) and client (Ruby in Silverlight). Sounds cool, let's see where that will go.
Scaling vs Performance
I thought performance was going to be the hot topic this year. I was proven wrong. The majority of Rails crowd now thinks it's easier to "scale" rather than to "optimize". Yeah, good old "add more hardware" approach with some new techniques added to make that process easier.
Michael Koziarski was probably the only one to speak about performance and tell the right thing. The idea is that it's always possible to improve something in Rails application by optimizing it or even optimizing Rails itself and the process to do that is easy - measure to find what's slow, fix it and measure again.
This measure-fix-measure is not a revelation and there're great tools to do that like ruby-prof and KCachegrind (see my previous blog post on profiling). I just wish more people used it.
After RailsConf Jeremy Kemper did some great work in optimizing Rails further. Also it's cool to see that Jeremy added performance test generators into Rails. I do hope that those tests will help people to make performance improvement the integral part of Rails application development process.
Speaking about profiling, Scott Barron and Chad Humphries from EdgeCase did a nice presentation about using DTrace with Ruby. DTrace is what you can use instead of ruby-prof (or together with ruby-prof) on development machines for regular profiling. But more interestingly, thanks to its low resource footprint, DTrace can become the real-time profiling solution for your production app (in case you deploy on Leopard or Solaris). This way you would be able to find slowdowns that happen rarely or happen only under heavy load on production machines. I only wish I had such tool available on Linux (to profile Acunote of course).
Final Thanks
Wrapping up this overview, I'd like to thank all speakers for great talks, especially Yehuda Katz (DataMapper presentation), Jeremy Kemper (Rails 2.1 keynote), Michael Koziarski (Rails performance), Adam Pisoni (Skynet) and Stephen Midgley (Complex searching in Rails) for the in-depth high-quality technical talks I've enjoyed so much.
I had a great time at RailsConf and hope you did that too, see you next year.