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:
2 comments:
Just to clarify, JRuby 1.0.1 really didn't have any intentional performance fixes in it. Pat mentioned that, but I wanted to state it again. And we have certainly started hitting performance harder since 1.0, but almost all that work is in svn trunk and will go into the 1.1 release for November.
Thanks for running the numbers again Pat!
And what about memory consumption?
Post a Comment