Paul F. wrote:
Probably a dumb question, but anyway…
What overhead cost is involved in using JRuby compared to using raw Java?
For example, is there a significant overhead in using a ruby hash
compared to java Hashmap?
Another example, does JRuby use java NIO under the hood?
Yes, the IO subsystem is largely implemented using NIO already, though
there’s certainly room for IO performance improvement. I think we do
pretty well now though.
What ruby functionality is worth replacing with the java functionality
implemented with a ruby call?
Hope you get what I am on about…
The core classes are all implemented in Java, so performance should be
pretty good. In some cases, it could be better; byte-based strings
have less overhead and use less memory than char-based strings, for
example, and our Array class is copy-on-write which reduces memory
overhead and operations like slicing.
We do incur overhead for a few things related to Ruby:
- Dynamic call overhead is ever-present, though we do more each release
to reduce it. It will have less effect if your operations against core
classes are more coarse-grained.
- Pure-ruby code will probably never be as fast as Java, even with all
our best tricks, since at a minimum it will always have to guard against
methods being redefined, constants replaced, and so on.
- –fast removes some of the overhead associated with Ruby logic, but
it’s not 100% safe yet. We’re getting there. JDK7/invokedynamic
- Calling Java libraries outside of our core classes generally has more
overhead, especially if strings are being passed around (since we have
to decode/encode both ways). We also improve this with each release, but
it’s something to watch out for.
In general, there’s a few rules of thumb:
- Ruby code is slower than Java code.
- Ruby core classes should be pretty fast, considering how much they do
- Java classes called through Java integration have a higher-per-call
cost than calling Ruby code or Ruby code clases that may be outweighed
by the perf gains from their being Java.
- Anything that’s obviously slower than you expect it to be should be
reported as a bug and we’ll try to improve it.
To unsubscribe from this list, please visit: