Mike McKinney wrote:
Was goofing around, decided to write a blog post about how different
languages do the same thing (read and spit out file contents)... blog
post here:
http://huikau.com/2007/11/25/simple-file-io-in-different-dynamic-languages/
I got curious about the JVM impls, timed them and figured I would
share the results with this list:
lang real time lang ver
RHINO: 0m0.310s (1.6R2)
GROOVY: 0m0.885s (1.0)
SCALA: 0m1.312s (2.6.0)
JRUBY: 0m1.668s (1.1b1)
Not the most controlled test, just used built-in 'time' for Mac OS
X... (i.e. time jruby fileTest.rb) This doesn't isolate the file IO
from the environment setup... but to a new user, this time counts.
(time spent waiting for your command line to return control.) Simply
running: jruby -e "a='a'" is only slightly faster if at all!
So you're measuring total execution time including startup for a small
file? If so, then these numbers are not too surprising.
I have questions:
1. does the overall warm-up time for JRuby include loading actual .rb files?
It includes everything, from loading .rb files to compiling the script
on the command line to binding all methods on all Ruby classes (by
generating small stub classes for each method) to actual execution.
2. is there a plan to compile all Ruby .rb files and stick them in a
jar for possible performance boost?
At the moment, this doesn't appear to give much of a performance boost
at startup, since class loading/verification ends up actually being
*slower* than just parsing the .rb file. We're fighting an uphill battle
against the verifier here.
3. while we're at it... how about compiling all Gems to jars?
(command line option?) I swear I heard this idea floating around
somewhere...
Also considered, but unlikely to improve startup time; if we support it,
it would be to reduce the time until gem code JITs in-memory, since the
majority of it would already be compiled. It would reduce warm-up time
but not startup time.
4. since I know my tests were not very scientific by any stretch...
what are some opinions on how to gather this type of data (speed,
determining JVM startup vs. environment load, etc.)
If you're interested in IO performance, put time measurements into the
script itself; that will exclude startup time. If you're interested in
startup time, we have a number of benchmarks included in JRuby that
basically spin up the basic runtime; actual startup will be that plus
the cost of loading user code (which should usually be fairly small, or
at least comparable to C Ruby).
Rhino's numbers from the command line may not be attainable due to the
scope of the language... but it's something to strive for.
If this is Rhino in interpreted mode, that's probably why startup is so
much better. You may try some of the following options to JRuby to
improve startup time, and please report your results.
-J-Xverify:none (disable class verification, not recommended for real apps)
-J-Djruby.reflection=true (disable code-generated method bindings)
-C disable all compilation
We are aware of the startup speed issue, and we'd love to find a good
answer. But the goals of fast long-term execution and fast startup are
at cross purposes on current JVM implementations. So it's a tricky problem.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
