From: Charles Oliver Nutter <charles.nutter@...>
Date: 2007-11-07T16:29:03+09:00
Subject: Re: JRuby performance questions answered

Roger Pack wrote:
>> Coincidentally, I did grab 1.1b1 so the benchmarks game has new
>> measurements
>>
>> http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=jruby
> 
> Wow it would appear that jruby is indeed faster, and indeed uses a lot 
> more memory :)  (or maybe that's just startup overhead).  thanks for a 
> good program!

I just committed an addition to JRuby that allows you to spin up a 
"server" JRuby instance (using "Nailgun") in the background and feed it 
commands. See the startup difference using this:

normal:

~/NetBeansProjects/jruby $ time jruby -e "puts 'hello'"
hello

real    0m1.944s
user    0m1.511s
sys     0m0.138s

nailgun:

~/NetBeansProjects/jruby $ time jruby-ng -e "puts 'hello'"
hello

real    0m0.103s
user    0m0.006s
sys     0m0.009s

Here's a post from the JRuby list describing how to use this, for those 
of you that are interested. Also, this allows you to avoid the startup 
memory cost for every command you run since you can just issue commands 
to that running server and it will re-use memory. After running a bunch 
of commands on my system, that server process was still happily under 
60M, and never went any higher.

...

I've got Nailgun working with JRuby just great now.

bin/jruby-ng-server
bin/jruby-ng

If you want to use the server, say if you're going to be running a lot
of command-line tools, just spin it up in the background somewhere.

jruby-ng-server > /dev/null 2> /dev/null &

And then use the jruby-ng command instead, or alias it to "jruby"

alias jruby=jruby-ng

You'll need to make the ng client command on your platform, by running 
'make' under bin/nailgun, but then everything should function correctly.

jruby-ng -e "puts 'here'"

The idea is that users will have a new option to try. For JRuby, where
we have no global variables, no dependencies on static fields, and
already depend on our ability to spin up many JRuby instances in a
single JVM, this ends up working very well. It's building off features
we already provide, and giving users the benefit of a fast,
pre-initialized JVM without the startup hit.

I think we're probably going to ship with this for JRuby 1.1 now. It's
working really well. I've managed to resolve the CWD issue by defining
my own "nailMain" next to our existing "main", and ENV vars are being
passed along as well. The one big remaining complication I don't have an
answer for just yet is OS signals; they get registered only in the
server process, so signals from the client don't propagate through. It's
fixable of course, by having the client register and the server just
listen for client signal events, but that isn't supported in the current
NG. So there's some work to do.

All the NG stuff is in JRuby trunk right now. Give it a shot. I'm 
interested in hearing opinions on it.

- Charlie