A large part of startup time is out of our hands, but we continue to look for workarounds. Most current startup slowness is due to the JVM itself running slow

A large part of startup time is out of our hands, but we continue to look for workarounds. Most current startup slowness is due to the JVM itself running slow during the first few seconds of execution. Ruby scripts execute as they boot, which means we have to parse and run them. But until the JVM's been up for a little while, nothing in JRuby itself has even JITted to native code...and interpreted JVM bytecode runs even slower than Ruby on most of my tests. The other complicating factor is the fact that Ruby applications run so much code on boot. RubyGems, for example, degrades startup time O(n) based on how many gems you have installed. Hacks like faster_rubygems (gem install faster_rubygems) help, but changes are needed in RubyGems proper. In any case, we feel the startup pain too. I've blogged a few tips about startup time here: http://blog.headius.com/2010/03/jruby-startup-time-tips.html http://blog.headius.com/2010/03/jruby-startup-time-tips.html, and I've described some of the challenges here: http://blog.headius.com/2010/06/my-short-list-of-key-missing-jvm.html http://blog.headius.com/2010/06/my-short-list-of-key-missing... We're working on it...we really are. We're just fighting against a decade of JVM folks who never run command-line tools.