Hi Folks,

I've been working on an application for a while now using MRE, and for a
variety of reasons, I need to get things working with JRuby.  I was
pretty astounded by a couple of things:

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               

However, I have to say that I was blown away by the performance
*increase* of a particular operation in my application.  Here's the
comparison of the timings:

MRE:	15.54s
JRuby:	 4.56s

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)?

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]



I wasn't expecting this kind of performance difference, but I have to
say that I'm quite happy about it.  :)

Great work to the JRuby team!

Cheers,

ast

P.S. No, I haven't tried it on YARV, and I'm not particularly interested
in benchmarks.  This was just something that I noticed in the course of
doing my work that I wanted to share and see if other people had seen
this kind of behavior.
-- 
Andrew S. Townley <ast / atownley.org>
http://atownley.org