Home > Development > 50% performance boost, for free?

50% performance boost, for free?

Wouldn’t it be nice to live in a world where you can wake up one day and have some project of yours just magically run 50% faster? Well my friends, JRuby is a world of mystery and amazement. In the past few days the JRuby team has been working feverishly on their Java integration rewrite. Along the way Charles Nutter managed to clean up the number of layers a Ruby call had to go through to get to Java. The net result: my test case for Gemini that I posted about earlier when from a frame rate of 27 fps to 40 fps. None of my actual code changed, I just swapped out the jruby.jar for a newer build. Swapping them back takes me back down to the 27 fps range. So, mana does fall from heaven occasionally, at least in JRuby land.

Advertisements
Categories: Development Tags: ,
  1. July 25, 2008 at 8:59 am

    Nice wonder how much it helped across a wider range of Ruby projects. I am hoping to give JRuby a try sometime for a side project, for now I am on real Ruby.

  2. July 25, 2008 at 10:25 am

    Kudos to them for trimming the fat, but don’t mistake it for ‘free’ performance. It’s performance that was going to waste before, so don’t expect it to _keep_ doubling.

    Still pretty awesome though, I wish 1.9 / MRI development moved this quick.

  3. dkoontz
    July 25, 2008 at 11:32 am

    Justin George:

    By that token, would Java have been getting faster over the last 10 years “for free”? The original JVM’s were certainly not as efficient as today’s version. I think that trimming the fat vs finding a better implementation are fine lines of distinction unless you have some clearly wasteful procedure going on. Maybe this was the case with the Java integration changes but I’d prefer to think of it like “adding JIT” or a better GC system. That is, a fundamentally better way of doing something that was considered acceptable the day before.

  4. July 31, 2008 at 2:26 pm

    I tend to agree with David’s assessment here (even though I’m biased). The “old” Java integration tier was designed to have a series of reflection-like types implemented in Java and all dispatch and object-wrangling with Ruby code. This was more “meta-circular” and feels right in some ways, but it also meant massive overhead for simple method calls, even under current JRuby. And ultimately, the features it provided were not really necessary if you could just get at the normal Java reflection types. So I see the current round of improvements more as a migration away from the old way and the features it provided toward a new way that supports features people actually use but that performs far better.

  1. July 30, 2008 at 11:11 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: