4 ms·

> What are some other reasons I might consider Rubinius? JRuby uses UTF-16 as its internal string encoding, so Rubinius is going to use a lot less memory. It c

> What are some other reasons I might consider Rubinius? JRuby uses UTF-16 as its internal string encoding, so Rubinius is going to use a lot less memory. It can also boot its VM more quickly since the client hotspot JVM has been largely neglected in favour of optimizing JIT for long-running processes. I would use JRuby for sure by default, but there may be places where these two things would disqualify it. Rubinius development also feeds into JRuby--I believe JRuby uses some of Rubinius's standard library (or at least it used to), and rubyspec came from Rubinius as well.

headius 15y ago
JRuby uses exactly the same in-memory format as Ruby, byte[]. We also support the Encoding logic from Ruby 1.9, again atop byte[]. JRuby actually has better String performance and encoding support than Java itself in many cases. Rubinius boots negligibly faster than JRuby; for simple scripts, JRuby takes around 0.5s on my system versus 0.35s for Rubinius. All implementations that JIT to get to full speed will have startup issues. JRuby does not use any of Rubinius's standard library. We do both share most of MRI's standard library, however. As for RubySpec; Rubinius started it, and JRuby is a very heavy contributor to the project. However JRuby also runs many other Ruby test suites, so we have not been as dependent on filling out RubySpec. We do both share implementation ideas and advocate for each other in debates with ruby-core. Hopefully in the future we can work together on adding new standard APIs as well (rather than unilaterally adding them to one implementation or the other).
- technomancy 15y ago
  I shouldn't be surprised, but my knowledge of the ruby world seems to be about two years out of date. I suppose any remaining additional memory usage is probably due to inheriting space/speed tradeoffs straight from upstream hotspot. It's great to hear that the startup time has improved so much.
  - headius 15y ago
    Actually a lot of the process size in JRuby is the fact that we need to set JVM's max size high for rare cases, but then the JVM happily grows to fill much of that size. If you choke it down to a smaller size, we're competitive with at least generational-GC impls like Rubinius (but still much larger than conservative-GC impls like MRI).

headius 15y ago

JRuby uses exactly the same in-memory format as Ruby, byte[]. We also support the Encoding logic from Ruby 1.9, again atop byte[]. JRuby actually has better String performance and encoding support than Java itself in many cases. Rubinius boots negligibly faster than JRuby; for simple scripts, JRuby takes around 0.5s on my system versus 0.35s for Rubinius. All implementations that JIT to get to full speed will have startup issues. JRuby does not use any of Rubinius's standard library. We do both share most of MRI's standard library, however. As for RubySpec; Rubinius started it, and JRuby is a very heavy contributor to the project. However JRuby also runs many other Ruby test suites, so we have not been as dependent on filling out RubySpec. We do both share implementation ideas and advocate for each other in debates with ruby-core. Hopefully in the future we can work together on adding new standard APIs as well (rather than unilaterally adding them to one implementation or the other).

technomancy 15y ago
I shouldn't be surprised, but my knowledge of the ruby world seems to be about two years out of date. I suppose any remaining additional memory usage is probably due to inheriting space/speed tradeoffs straight from upstream hotspot. It's great to hear that the startup time has improved so much.
- headius 15y ago
  Actually a lot of the process size in JRuby is the fact that we need to set JVM's max size high for rare cases, but then the JVM happily grows to fill much of that size. If you choke it down to a smaller size, we're competitive with at least generational-GC impls like Rubinius (but still much larger than conservative-GC impls like MRI).