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