Lionel Bouton
3/4/2008 2:44:00 PM
Michal Suchanek wrote:
> Hello
>
> I have tried to run my string munching application in JRuby, and I am
> quite pleased with the results.
>
>
> My string_arrays.each{|array| m=MunchedStrings.new; array.each{|str|
> m.munch str}; puts m.pretty_print } cycle tops at about 790MB ram, and
> the RSS even decreases when smaller arrays are processed. In contrast,
> the MRI tops at about 2.5G at the end of the cycle, and I have
> observed no decrease in RSS ever. Also notable is that after parsing
> the data file JRuby uses about 250MB ram as opposed 600MB used by MRI.
>
> These results were obtained with JRuby 1.1RC2 on OS X 10.4 with the
> included Sun JVM 1.5 versus current Debian ruby MRI packages
> (1.8.6).
>
> I did not check for differences in the result yet, and I could not run
> the jruby tests as the junit.jar is not included, at least not in the
> place indicated by readme.
>
> The JRuby 1.0 that is packaged for Debian does not work for me. It
> does not understand -KU and spams lots of warnings about $; being
> uninitialized.
>
> I know that it would be nice to provide the application for testing
> but I cannot release the data.
> I might to do a simplified version that runs on random data eventually.
>
> Anyway, other people who have trouble with large memory usage might
> try JRuby as well. It runs 1.8 code without modification (I
> intentionally did not use any non-core extension to make the
> application portable although it might have simplified the use of
> utf-8 strings a bit).
I've briefly tried Jruby 1.0 and 1.1RC2 with the latest Sun 1.6 JVM on
Linux 32bit when we benchmarked the Ruby Quiz #157 submissions, but I
was not impressed (I didn't check the memory usage though):
- both threw a NulllException in the Jruby code when running one of the
submissions (you can easily reproduce this by looking for the benchmark
posts in the archives, there was an URL for a page with all the relevant
code), you just had to launch the benchmark to get it. There was no way
of protecting from this as it was out of Ruby's scope (ie a begin rescue
couldn't catch it),
- 1.0 was slower than MRI (between 2x and 3x) and 1.1RC2 slightly faster
(5 to 10%), the code was mainly doing floating point computations.
- Launching the JVM is 10x slower than MRI (unusable for small scripts
designed to return quickly).
JRuby is still on my watch list (ruby-gettext is now pure Ruby so one of
my main obstacle to using it in production was recently removed) but I'm
not sure it is quite here yet (aborting the first program I try with it
with a NullException is not encouraging).
For the small scripts problem with the JVM loading, at some point I've
read that future JVMs would have the ability of acting as resident
interpreters (ie: a JVM is always running in the background and new
instances are simply feeding it the code instead of loading a whole new
JVM). I didn't found any documentation on that in the java man page of
my local Sun 1.6.0.03 JDK install though :-(
Lionel