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.
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.
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).
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.
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.
Object sizes in JRuby are certainly larger, especially if you run on a 64-bit JVM which necessarily has 64-bit reference fields for all object references (basically everything in Ruby). It doesn't surprise me at all to see a single-threaded case with a lot of objects use more memory, but it would be interesting to see how much of that was unused heap space and how much was actually live data. MRI's less-efficient conservative collector can live in a smaller memory space, but you sacrifice performance.
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.