5 ms·

JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling

JRuby would be the future if the startup times weren't so horrendous. It makes it very unpalatable for scripting. Nailgun is not robust enough. I have a feeling this is going to be more of a JVM problem than something Nutter and team is going to tackle. So is the future Rubinius and JRuby?

jon_dahl 16y ago
For scripting, that's definitely a problem. But it's not a big deal for long-running processes (e.g. a web application server). But Ruby definitely benefits from both: a fast Ruby with ~zero startup time, and a fast Ruby on the JVM. 3 years ago, Ruby implementation problems became the hot topic at Ruby conferences. Ruby was a beautiful language with an ugly implementation. It's great to see that the community has executed on this concern.
- rbranson 16y ago
  While I agree that it's not important for long-running applications, there is still a lot of scripting done in Ruby, and it's very frustrating to get a a 5-to-10 second wait just to tell someone their arguments were invalid. Waiting that long for tests is also such a drag on iteration. I think once JRuby has stabilized the native gem support and has some sort of Passenger-like deployment option (Glassfish and Warbler isn't quite there yet), we'll see some big players built on MRI start to move their Web applications to the platform.
  - rue 16y ago
    Use MRI for short-lived and JRuby for long-lived. Problem solved?
donw 16y ago
The tradeoff is that you get a much more stable runtime, true multithreading, and the ability to play ball with everything in the Java ecosystem. Sure, it takes longer to start up, but we're talking a few seconds here, which is nothing for a long-running webapp. Plus, the JVM is rock-solid, has very predictable memory usage, and also has tons of monitoring infrastructure to bring to bear against problems. Yeah, I'm a fan.
cageface 16y ago
I'm much, much more concerned about the memory usage of JRuby than the startup times. For toss-off scripts I can keep using MRI. I've read that JRuby memory usage scales better than MRI though, so you pay a higher cost upfront but can actually accommodate more workers on the same hardware. I haven't gotten far enough in my exploration of JRuby to see if this is the case in my own apps. Hats off to all the devs working on bringing us a better Ruby runtime. I realize it's a lot of work.
- rbranson 16y ago
  In my tests, it's still worse than MRI. Memory-wise, the best between 1.8.7, 1.9.1, and JRuby 1.5 was still 1.8.7. Of course, if this is the difference between storing stuff in memory and loading from disk, 1.8.7 would be faster by orders of magnitude. The ability to use stable, high-performance JVM libraries trumps this concern in many cases though.
  - headius 16y ago
    It's also worth pointing out that while a JRuby/Rails instance might take 100-200MB, that's all you need to scale a site across pretty much any number of cores. MRI and REE both need to spin up multiple processes to handle concurrent requests, so very quickly the JRuby memory size becomes a tremendous win (think of 25-50 MRI instances using 20-50MB of memory each...you get the picture).
    - cageface 16y ago
      Yeah that's what I'm hoping to see as I transition a couple of test apps over. The scala/lift folks see this as a big advantage for their JVM web stack too.
    - rbranson 16y ago
      Yeah I see that. My tests primarily revolved around single-threaded event driven code, and retaining large container objects (millions of objects). MRI was much more efficient. I understand that there's a lot more going on under the hood in JRuby just to make this possible, but for this use case, the result is what mattered. Although we ended up using Tokyo Tyrant (with a hack to pre-disk-cache all the data) anyway.
aarongough 16y ago
It's worth noting that startup times with 1.9 are longer than with 1.8 (in my experience anyway). Startup times for my 1.8 instances on Heroku are sub-second. Whereas instances running 1.9 are 6+ seconds! Disclaimer: I haven't dug into this issue much, so its possible other factors are the cause...
headius 16y ago
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.
isaacforce 16y ago
I have both MRI and JRuby installed on my systems. For quickie scripts I use 'ruby' and for anything with a noticeable runtime (Or multi-core processing!) I use 'jruby'. I'm sure the JRuby fellows will continue working on startup time, but for me at least, it's not an issue. I think having a Ruby toolbox instead of a single big hammer is a win for everybody.
- headius 16y ago
  We hear this a lot. Hopefully we can keep improving startup times, but when it's possible to use either Ruby or JRuby, it makes a pretty good combination.
Confusion 16y ago
It's definitely a JVM problem, but contrary to Java, there is a sort of REPL available. Instead if writing a file, modifying it and running 'jruby my-script.rb', just issue 'load myscript.rb' in your (j)irb. That makes for much faster iterations.

jon_dahl 16y ago

For scripting, that's definitely a problem. But it's not a big deal for long-running processes (e.g. a web application server). But Ruby definitely benefits from both: a fast Ruby with ~zero startup time, and a fast Ruby on the JVM. 3 years ago, Ruby implementation problems became the hot topic at Ruby conferences. Ruby was a beautiful language with an ugly implementation. It's great to see that the community has executed on this concern.

rbranson 16y ago
While I agree that it's not important for long-running applications, there is still a lot of scripting done in Ruby, and it's very frustrating to get a a 5-to-10 second wait just to tell someone their arguments were invalid. Waiting that long for tests is also such a drag on iteration. I think once JRuby has stabilized the native gem support and has some sort of Passenger-like deployment option (Glassfish and Warbler isn't quite there yet), we'll see some big players built on MRI start to move their Web applications to the platform.
- rue 16y ago
  Use MRI for short-lived and JRuby for long-lived. Problem solved?

donw 16y ago

The tradeoff is that you get a much more stable runtime, true multithreading, and the ability to play ball with everything in the Java ecosystem. Sure, it takes longer to start up, but we're talking a few seconds here, which is nothing for a long-running webapp. Plus, the JVM is rock-solid, has very predictable memory usage, and also has tons of monitoring infrastructure to bring to bear against problems. Yeah, I'm a fan.

cageface 16y ago

I'm much, much more concerned about the memory usage of JRuby than the startup times. For toss-off scripts I can keep using MRI. I've read that JRuby memory usage scales better than MRI though, so you pay a higher cost upfront but can actually accommodate more workers on the same hardware. I haven't gotten far enough in my exploration of JRuby to see if this is the case in my own apps. Hats off to all the devs working on bringing us a better Ruby runtime. I realize it's a lot of work.

rbranson 16y ago
In my tests, it's still worse than MRI. Memory-wise, the best between 1.8.7, 1.9.1, and JRuby 1.5 was still 1.8.7. Of course, if this is the difference between storing stuff in memory and loading from disk, 1.8.7 would be faster by orders of magnitude. The ability to use stable, high-performance JVM libraries trumps this concern in many cases though.
- headius 16y ago
  It's also worth pointing out that while a JRuby/Rails instance might take 100-200MB, that's all you need to scale a site across pretty much any number of cores. MRI and REE both need to spin up multiple processes to handle concurrent requests, so very quickly the JRuby memory size becomes a tremendous win (think of 25-50 MRI instances using 20-50MB of memory each...you get the picture).
  - cageface 16y ago
    Yeah that's what I'm hoping to see as I transition a couple of test apps over. The scala/lift folks see this as a big advantage for their JVM web stack too.
  - rbranson 16y ago
    Yeah I see that. My tests primarily revolved around single-threaded event driven code, and retaining large container objects (millions of objects). MRI was much more efficient. I understand that there's a lot more going on under the hood in JRuby just to make this possible, but for this use case, the result is what mattered. Although we ended up using Tokyo Tyrant (with a hack to pre-disk-cache all the data) anyway.

aarongough 16y ago

It's worth noting that startup times with 1.9 are longer than with 1.8 (in my experience anyway). Startup times for my 1.8 instances on Heroku are sub-second. Whereas instances running 1.9 are 6+ seconds! Disclaimer: I haven't dug into this issue much, so its possible other factors are the cause...

headius 16y ago

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.

isaacforce 16y ago

I have both MRI and JRuby installed on my systems. For quickie scripts I use 'ruby' and for anything with a noticeable runtime (Or multi-core processing!) I use 'jruby'. I'm sure the JRuby fellows will continue working on startup time, but for me at least, it's not an issue. I think having a Ruby toolbox instead of a single big hammer is a win for everybody.

headius 16y ago
We hear this a lot. Hopefully we can keep improving startup times, but when it's possible to use either Ruby or JRuby, it makes a pretty good combination.

Confusion 16y ago

It's definitely a JVM problem, but contrary to Java, there is a sort of REPL available. Instead if writing a file, modifying it and running 'jruby my-script.rb', just issue 'load myscript.rb' in your (j)irb. That makes for much faster iterations.