4 ms·
> so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's strea
by azth 13y ago
> so I sometimes transliterate Go code to Java (the resulting code is always of similar length, perhaps with a slight advantage to Java, now with Java 8's streams and such).
How does performance compare?
- pron 13y agoAs usual, that depends. Java performs better on function calls (because of the JVM's inlining JIT) and garbage collection. But because fibers are not native to the JVM, they do incur some overhead. If the fibers perform no work, then you're essentially just measuring the overhead, and Go would perform better. The more work is done, the more the advantage goes to Java. With regards to IO, fiber-blocking IO currently uses the JVM's asynchronous NIO (which uses epoll/kqueue) under the covers, unchanged. But Java's async NIO is intended to be thread-safe, so there is lots of unnecessary synchronization going on there. The result is about 7% slower than Go. Again, the more computation work you do, the more the performance swings in favor of Java. We can do much better with IO by plugging our own NIO provider (Java's dynamic linking everywhere is awesome), but because the performance is really good as it is, it's not a top priority for us at the moment. EDIT: the reason I would use Java over Go for all the "serious stuff" isn't primarily performance, though. It's the incredible monitoring and profiling capabilities, hot code swapping and other stuff that's possible with full dynamic linking.
- azth 13y agoThanks for the insightful reply. :)