4 ms·
That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance do
by FooBarWidget 11y ago
That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance doesn't kick in until the JVM is sufficiently warmed up, which means JRuby shines mostly for long-running tasks. Warming up can take a few minutes, although some people tell me that I should warm up for half an hour (!).
On the flip side, JRuby starts much more slowly than MRI. This is a general Java problem: startup times are problematic. Also, code reloading performance may be worse than MRI, so things may be slow in development. JRuby is optimized for production-level long-running workloads. So something like 'rake' will likely take longer with JRuby.
- astrodust 11y agoIn practice I've found the start-up times aren't all that different. The drag is more pronounced on older hardware, though. A current i5 or i7 system with an SSD is usually roughly the same.
- FooBarWidget 11y agoThat is very contrary to my experience. A Rake task in a Rails project almost always takes somewhere like 15-20 seconds just to start up (on MRI it's around 2-5). Just today, I tried to run the Middleman static site generator. Where on MRI, Middleman starts building after around 3 seconds, on JRuby it starts building after around 10 seconds. And I'm on a 2012 Macbook Air.
- chaostheory 11y agoFor things like Rails, that are going to be running all the time, does the JVM warm up time really matter?
- ch4s3 11y agoNo, its just a drag to TDD with.
- rurounijones 11y agoI and others have had success with MRI on dev and JVM in prod to get around this. Maybe not for everyone but as long as you know what you are doing it is viable I think.
- headius 11y agoWe've added a --dev flag to JRuby that attempts to turn on fast-starting flags in JRuby and the JVM to reduce startup time. It can be as much as twice as fast. We continue to try to improve startup performance, and hopefully over the next year we can close the gap a bit more.