JRuby 1.0.1 - Real World Performance

The other day, Thomas Enebo and the JRuby gang cut a 1.0.1 release of JRuby and I finally got around to benchmarking it against my LogWatchR app. I used the same data set and Ruby versions as previously (I need to upgrade my 1.9.0 install to see how that work's been going, but it won't happen today). (You can see the previous version of this benchmark here.)

This time around, JRuby showed significant performance improvements. (Oddly, the 1.8 and 1.9 benchmarks looked better too, I don't know if that's from a small code change or just that my system is running a little bit lighter these days.) My stock Ruby install ran the tests in an average of 9.294 seconds (+/- .41 seconds). My 1.9 install run them in 9.394 seconds (+/- .11). The JRuby results are a bit more involved:

• no flags
  14.754 sec (+/- .26)
• jruby -J-Djruby.jit.threshold=0 -J-server -O logwatcher.rb
  19.370 sec (+/- .31)
• jruby -J-Djruby.jit.threshold=0 -O logwatcher.rb
  13.226 sec (+/- .30)
• jruby -J-Djruby.jit.threshold=1 -O logwatcher.rb
  13.256 sec (+/- .25)

All this means that JRuby is now 142-159% as slow as the installed version of Ruby for LogWatchR. That's a pretty big improvement over the 223-278% it was at the last time I ran the tests. Not bad for a test that Charles Nutter told me didn't have many performance fixes in it. I can't wait to see what happens when the JRuby guys actually start to work on performance.

rubinius is still not up to running LogWatchR, but it looks like the 0.10 version (expected in October) will be the release I get to start using. In the meantime, rubinius performance is starting to look pretty good too.

If you enjoyed this article on profiling, you might also want to look at these:

• Some Real World Performance Notes
• More Real World Performance Notes
• JRuby 1.1 Performance Numbers

Three Lego Books

My son has gotten into LEGO Mindstorms NXT this year (thanks to a friends kind Christmas gift). Since he’s always trying to figure out ways to build cool NXT stuff (and for ways to spend his lawn mowing money), he’s picked up three cool NXT books from Apress:

• Advanced NXT
• Extreme NXT
• LEGO MINDSTORMS NXT: The Mayan Adventure

He’s planning on writing book reviews for each of these books, and I’ll post those here once he’s written them. I think they’re all pretty cool, and I’m looking forward to some NXT filled Saturday afternoons later on this summer.

rocaml interview leftovers

I put together a mini-interview with Mauricio Fernandez about his new Ruby/OCaml bridge, rocaml. You can read most of it over at Linux Journal, but here’s a little bit that didn’t fit in too well over there.

---

zenspider has talked before about wanting to build a OCaml module for RubyInline, what are the chances that you and ROCaml might become involved in something like that?

I am not sold on the advantages of RubyInline in the case of Objective Caml, and its philosophy differs to some extent from rocaml’s, as exemplified by the way it converts Ruby values into native OCaml types and vice versa.

RubyInline makes sense for C because it can be used for small routines that can make use of low-level knowledge of the implementation (such as the RArray, RString, RFloat, etc. structures) to make some operation faster. This is where embedding C code in your Ruby sources is a good idea, since creating an extconf.rb and a separate source file just isn’t worth it for a function taking but a few lines of code. On the other hand, when you don’t need access to Ruby’s C API and your C code is pretty general (except maybe for the fact that it takes simple Ruby VALUEs), putting it in a separate file seems more sensible.

rocaml, on the other hand, is more about writing OCaml code that doesn’t know it’s being called from Ruby, both for practical (code reuse, ability to migrate more functionality from Ruby to OCaml if needed…) and efficiency reasons.

Adding OCaml support to RubyInline via rocaml is not amongst my priorities; as I said, it doesn’t make that much sense for the kind of things I’m using rocaml for at the moment. But it doesn’t seem hard, so I will take a look at it.

JRuby 1.0 -- Congratulations guys!

I’m a day late on this one, but the JRuby team cut their 1.0 release yesterday. This release has targeted 1.8 compatibility, and they’ve done a great job. Performance still lags a bit, but I think they’re on the right track to get things going there too.

I’m looking forward to seeing what these guys pull out of their hat over the next six months. I really hope they spend more time on performance than on adding 1.9 features, but since I’m not sending in patches I don’t have a lot of say in it. I’m also hoping that the next six months sees more cross-pollination between XRuby, rubinius, and JRuby—the different approaches are each paying off in different ways so far.

I’ve installed the 1.0 binary release of JRuby (an incredibly easy install, by the way) and run it through the LogWatchR time tests I’ve been running, but I get the same results as last time (with the 0.9.9 release) so I won’t bother recreating those tables here.

June Blogging Contest

June brings us to the sixth, and final, month of the On Ruby/Apress blogging contest. It’s been a great ride, and I’d like to thank the fine folks at Apress for making it happen.

This month, David Berube, author of Practical Ruby gems, will be our guest judge. In honor of David’s book, I wanted to close things out with a Ruby Gems theme:

“Other than Rails, what is your favorite Ruby Gem, and why?”

Write a blog entry about your favorite gem. Tell the world what it’s good for and how to use it and drop a URL in the comments below. If we think you’ve written te winning entry, you’ll get three Apress books of your choice. Simple as that.

Can’t narrow it down to just one gem? No problem, you can enter more than once. Already entered and can’t think of anything to do? Come back and read the other entries—who knows, you just might find that gem that you’ve been looking for.

Good luck, and get writing!