4 ms·
JRuby question -- Why is it that much slower? I'd have thought that part of the point was to take advantage of the JVM's built in optimization.
by Jgrubb 13y ago
JRuby question -- Why is it that much slower? I'd have thought that part of the point was to take advantage of the JVM's built in optimization.
- mml 13y agoMy question as well. Every perf benchmark I've seen of jruby over the years, it's much faster than MRI (given time to boot & JIT anyway). I think this guy's numbers are very suspect.
- exabrial 13y agoI was about to say the same thing... I thought JRuby was king for long running Ruby apps (like a Rails app) for many years now... seems very suspect.
- jshen 13y agoI've benchmarked MRI vs jruby a number of times over the years on real apps and MRI usually cones out faster on average with worse numbers at 95th and 98th percentiles due to GC performance. I never took the time to figure out why it is faster, but I assume that it is due to C libraries being faster for json serialization and my apps doing primarily json serialization after fetching from the database. Edit: I should test the performance of the json libs, which would be easy to do
- sluukkonen 13y agoLooks like it's running with the threadsafe mode off. That would probably give JRuby an edge, as it's able to take advantage of greater thread parallelism than MRI. No idea if he's letting the JVM warm up enough either.
- jrochkind1 13y agoDepending on how you are deploying the ruby app. As far as I know, Passenger Enterprise and Puma are the only multi-platform ruby rack app servers that support multi-threaded concurrent request dispatch. There may be other jruby/java-only deployment scenarios that support concurrent request dispatch. Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently!
- sluukkonen 13y ago> Without concurrent request dispatch, jruby's hypothetical greater thread parallelism is unlikely to effect requests-per-second benchmarks. Also, the benchmarking test would have to be willing to issue requests concurrently! That's a good point. That said, JRuby would most likely benefit from a concurrent test, as the thread-per-request model of JRuby can scale much higher than the process-per-request model which is used a lot in the MRI world.
- jrochkind1 13y agoYes, that's what I said, _if_ you have an app server that supports concurrent request handling. If you are deploying a JRuby app with thin or unicorn or the free version of passenger -- you don't get multi-threaded concurrent request handling.
- falloutfar 13y agoit uses an old hardware, with an old JDK, etc.
- jeltz 13y agoOld hardware should not matter, but old JDK is huge.
- phillmv 13y agoI'd wager that a bigger goal is being able to take part of the Java ecosystem. That said, we really need to know which flags he's running Jruby with - and which The internet tells me that you achieve better performance with -server at the expense of a bigger start-up time penalty. Anecdotally, it takes a while for the JIT compiler to find the hotspots in your code and optimize them away. All of this will depend on how Jruby-rails keeps code in memory, yadda yadda. Someone who actually has used Java/Jruby recently can chime in with more details.
- Freaky 13y agoA lot of optimizations are off by default, or completely unavailable because he's using JDK 1.6. See https://github.com/jruby/jruby/wiki/PerformanceTuning https://github.com/jruby/jruby/wiki/PerformanceTuning Startup time is slow because it needs to warm up the JIT. Same with Rubinius, which is mysteriously missing from most of these graphs. Memory consumption partially depends on how much you tell the JVM to use - it'll run the garbage collector more or less aggressively to keep within that bound - default appears to be min(system memory/4, 1GB). That's not to say it doesn't need more memory than MRI, but you should factor in the concurrent native threads allowing one process to serve many clients, and the precise compacting GC limiting memory fragmentation and associated heap bloat with long-running processes.
- bch 13y ago> Startup time is slow because it needs to warm up the JIT. Question (I'll end up simultaneously googling...): if the code doesn't change between restarts, is there a way one can preserve JIT statistics, so the JVM doesn't have to rediscover hotspots? Like an RDBMS able to load custom statistics for its plan engine.