Charles Oliver Nutter
4/24/2009 3:22:00 PM
Andrew S. Townley wrote:
> First, JRuby takes up a lot more memory than MRE, which I suppose is the
> nature of the beast. It can't be 100% apples to apples comparison,
> because to do what I'm doing I'm using different UI toolkits in each
> environment. However, for comparison (top output):
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 6042 ast 20 0 423m 105m 22m S 0 2.7 1:42.55 ruby
> 6058 ast 20 0 816m 329m 11m S 110 8.3 0:56.71 java
There are ways to mitigate this, somewhat, but it's also the nature of a
VM with a generational garbage collector to be larger in memory.
> MRE: 15.54s
> JRuby: 4.56s
Very nice! We would probably improve even more on a longer run; this is
a pretty short timing, and anything under 10s doesn't really show our
full performance.
> The nature of the application is that it does a bunch of filesystem I/O
> operations, lots of regular expression checks, and lots and lots and
> lots of Hash lookups. This particular timing figure also has nothing to
> do with the UI environment. It's generated internally by code triggered
> by the UI.
>
> Would I be right in assuming that this performance difference is due to
> faster underlying performance of the relevant Java classes, or is it
> down to the execution speed of the VMs (or maybe a bit of both)?
For that kind of application most of the performance difference is
probably coming from our implementations of Regexp, IO, and Hash. IO is
usually a bit slower than MRI for us (needs work), but Regexp and Hash
are usually very good performance. And the JVM helps a lot as well; most
of our core classes have been written in a way that allows the JVM to
optimize them well.
You're probably seeing some boost from JRuby's execution performance,
which is pretty good as well. But I'd bet most comes from the core class
impls.
> The system environment details are:
>
> Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
> MemTotal: 4046672 kB
>
> ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]
> jruby 1.3.0 (ruby 1.8.6p287) (2009-04-21 r9535) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_11) [amd64-java]
The 64-bit JVMs take up quite a bit more memory, as would a 64-bit
implementation of anything (pointers at the very least become twice as
wide). If you have the option, you might try running in 32-bit mode
(-d32 passed to JVM, or -J-d32 passed to JRuby). But on 64-bit linux I
don't think there's a 32-bit JVM by default.
You can also try to choke the maximum memory down. By default, JRuby
will allow the JVM to grow its heap up to 512MB. You can modify this up
or down with the -Xmx JVM flag (or -J-Xmx JRuby flag). So the default
would be -J-Xmx512M and if you can run with less, you might be able to
force JRuby+JVM to use less memory at a possible cost of performance
(more GC).
- Charlie