7 ms·

is it faster than MRI?

fny 11y ago
The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/ http://www.isrubyfastyet.com/
- headius 11y ago
  These benchmarks are very small and do not run long enough for the JIT to really kick in. Many of them are also so synthetic as to be meaningless.
  - Freaky 11y ago
    50,000 requests aren't enough for the JIT to warm up?
pesnk 11y ago
Course it is. JRuby has been faster then MRI for a long time. That does not mean I use it for production.
- rurounijones 11y ago
  True in the 1.8 1.9 era. Against 2.2 it is not an automatic "Is faster"
  - headius 11y ago
    Ruby performance has not improved substantially since 2.0, and we should almost always be faster for straight-line workloads. If we're not...tell me.
- Twirrim 11y ago
  > That does not mean I use it for production. Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)
aurochs 11y ago
It should be faster. I haven't seen any newish real world benchmarks to that effect though. These web benchmarks give some conflicting results between MRI and JRuby : https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=query https://www.techempower.com/benchmarks/#section=data-r10&hw=... .
- headius 11y ago
  They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones for MRI, and as a result they perform worse. I know this is small consolation, but everything in the JRuby ecosystem is continuing to improve every day. When there's specific reproducible cases where we're slower, we take them very seriously.
dragonwriter 11y ago
JRuby used to be much faster than MRI (definitely so when MRI 1.8 was current), but MRI has gotten better faster than JRuby, and IIRC, its now mostly a mixed bag based on workload, particular application design choices, etc.
- headius 11y ago
  That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right, performance can be anywhere from two to ten times faster than MRI.
bradleyland 11y ago
It is a stated goal of the JRuby project to meet or exceed MRI performance. The team will actually accept issues/bugs if you can provide a (well structured and isolated) benchmark illustrating a performance deficiency relative to MRI.
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 ago
  In 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 ago
    That 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 ago
  For things like Rails, that are going to be running all the time, does the JVM warm up time really matter?
  - ch4s3 11y ago
    No, its just a drag to TDD with.
    - rurounijones 11y ago
pmontra 11y ago
What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately). I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/ http://www.sitepoint.com/ides-rubyists-use/). Anyway, I'm doing a bundle install with jruby on a Rails project right now. Let's see if it completes and passes the tests.
- pmontra 11y ago
  I've been doing some progresses but there are a few (almost) show stoppers. One is that startup is really slow. rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with. Second one: still immature. The PostgreSQL adapter warns NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2 support - check http://bit.ly/jruby-42 http://bit.ly/jruby-42 for starters Not something I want in production. Third one, now I'm stuck with the JDBC adapter not connecting to my developement PostgreSQL over a unix domain socket. Maybe it can't (perhaps JDBC does only TCP/IP) and I have to reconfigure PostgreSQL to accept connection to 127.0.0.1:5432. That means any other application I'm working with won't work anymore and I should reconfigure them. Summing up all together I'm not particularly eager to keep testing JRuby. Maybe somebody will solve those problems. I'll give another try to it next July.
  - cheald 11y ago
    It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no? The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.
    - pmontra 11y ago
      JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip). My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be negatively impacted. This is about the "ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC". The other one (unix domain socket) is a minor issue but any small nuisance loses developers along the way.
ericb 11y ago
At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP Client with keepalives helped with this. In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?
- cheald 11y ago
  I wrote Manticore (https://github.com/cheald/manticore https://github.com/cheald/manticore) because of my dissatisfaction with Ruby HTTP clients under JRuby; it uses the Apache HTTPComponents (completely sidestepping Ruby's stdlib http/networking stuff) and is extremely fast. It might be worth looking into for you.
- nirvdrum 11y ago
  Do you have anything you can point at regarding String performance? Everything I've seen shows JRuby being faster than MRI. But I'm looking to see if we can make it even faster than it currently is. Any pathological cases would be incredibly helpful.
  - ericb 11y ago
    I can send you an example. Can I drop you an email? I think also that we are friends on linkedin, coincidentally. I can message you there (if that is a useful way to get in touch?).
    - ericb 11y ago
      I sent an email to your email address at nirvdrum with what I've been looking at.
      - nirvdrum 11y ago
        I got it, thanks. And thanks for following up. I'll take a look and let you know what I find.
amalag 11y ago
You don't have to spawn a separate instance for each CPU core. Granted there are web servers that take care of some of that by having multiple workers.
juliangregorian 11y ago
If you need system-level bindings: no. If you use threading: yes.
- headius 11y ago
  What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.
  - juliangregorian 11y ago
    Ok, then why do none of the C app servers work in JRuby?
    - cheald 11y ago
      Because the C extension API isn't supported. Or to put it another way, you can call C libraries from JRuby, but you can't write C that calls JRuby. If you want to do that, you would replace it with a Java extension, instead. It's possible to offer "native extensions" for both MRI and JRuby from a gem by providing both via C and Java extensions, though.

fny 11y ago

The real advantage comes from the fact that JRuby isn't enslaved to a GIL like MRI, so you get JVM threads out of the box. Even with the JIT, JRuby (at least 1.7) isn't appreciably faster than MRI when running a single-threaded app: http://www.isrubyfastyet.com/ http://www.isrubyfastyet.com/

headius 11y ago
These benchmarks are very small and do not run long enough for the JIT to really kick in. Many of them are also so synthetic as to be meaningless.
- Freaky 11y ago
  50,000 requests aren't enough for the JIT to warm up?

pesnk 11y ago

Course it is. JRuby has been faster then MRI for a long time. That does not mean I use it for production.

rurounijones 11y ago
True in the 1.8 1.9 era. Against 2.2 it is not an automatic "Is faster"
- headius 11y ago
  Ruby performance has not improved substantially since 2.0, and we should almost always be faster for straight-line workloads. If we're not...tell me.
Twirrim 11y ago
> That does not mean I use it for production. Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)

aurochs 11y ago

It should be faster. I haven't seen any newish real world benchmarks to that effect though. These web benchmarks give some conflicting results between MRI and JRuby : https://www.techempower.com/benchmarks/#section=data-r10&hw=peak&test=query https://www.techempower.com/benchmarks/#section=data-r10&hw=... .

headius 11y ago
They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones for MRI, and as a result they perform worse. I know this is small consolation, but everything in the JRuby ecosystem is continuing to improve every day. When there's specific reproducible cases where we're slower, we take them very seriously.

dragonwriter 11y ago

JRuby used to be much faster than MRI (definitely so when MRI 1.8 was current), but MRI has gotten better faster than JRuby, and IIRC, its now mostly a mixed bag based on workload, particular application design choices, etc.

headius 11y ago
That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right, performance can be anywhere from two to ten times faster than MRI.

bradleyland 11y ago

It is a stated goal of the JRuby project to meet or exceed MRI performance. The team will actually accept issues/bugs if you can provide a (well structured and isolated) benchmark illustrating a performance deficiency relative to MRI.

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 ago
In 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 ago
  That 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 ago
For things like Rails, that are going to be running all the time, does the JVM warm up time really matter?
- ch4s3 11y ago
  No, its just a drag to TDD with.
  - rurounijones 11y ago

pmontra 11y ago

What I read is that it's faster for long running applications (example: web apps) because the JIT can optimize the code. It should be slower for anything else, example: tests (very unfortunately). I don't know what the edit-reload-check workflow could be with JRuby and how well it can integrate with editors (few Rubyist use IDEs, http://www.sitepoint.com/ides-rubyists-use/ http://www.sitepoint.com/ides-rubyists-use/). Anyway, I'm doing a bundle install with jruby on a Rails project right now. Let's see if it completes and passes the tests.

pmontra 11y ago
I've been doing some progresses but there are a few (almost) show stoppers. One is that startup is really slow. rails c takes 25 second to give a prompt vs 10 on with Ruby 2.2.2 and almost 0 after spring has started. It's not something that a developer likes to work with. Second one: still immature. The PostgreSQL adapter warns NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us finish 4.2 support - check http://bit.ly/jruby-42 http://bit.ly/jruby-42 for starters Not something I want in production. Third one, now I'm stuck with the JDBC adapter not connecting to my developement PostgreSQL over a unix domain socket. Maybe it can't (perhaps JDBC does only TCP/IP) and I have to reconfigure PostgreSQL to accept connection to 127.0.0.1:5432. That means any other application I'm working with won't work anymore and I should reconfigure them. Summing up all together I'm not particularly eager to keep testing JRuby. Maybe somebody will solve those problems. I'll give another try to it next July.
- cheald 11y ago
  It sounds like most of your issues are with JDBC/AR-JDBC rather than JRuby itself though, no? The startup time is annoying, though, especially in the context of TDD. I do know it's an area of active research, though. You should try launching with JRUBY_OPTS="--dev" and see if that helps, though.
  - pmontra 11y ago
    JRUBY_OPTS="--dev" lowered the startup time to 12 second, basically on par with MRI. Thanks! I googled you suggestion and I found https://github.com/jruby/jruby/wiki/Improving-startup-time https://github.com/jruby/jruby/wiki/Improving-startup-time I'll try a few suggestions that look like doing with spring does (Theine and Drip). My other problems are with JDBC but if database drivers don't support Ruby's largest use case (Rails with ActiveRecord) probably JRuby will be negatively impacted. This is about the "ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC". The other one (unix domain socket) is a minor issue but any small nuisance loses developers along the way.

ericb 11y ago

At least with the previous JRuby, for us the answer is "usually no." If you do any large string ops (hello JSON), or parsing, or use any ruby gems which use exception handling for flow control (which is cheap in MRI, but like 9ms per exception in JRuby) in a loop then you will be slower. Also, SSL connection negotiation is exceedingly slow in JRuby 1.7x (like 100ms) and this made our microservices tough. Using HTTP Client with keepalives helped with this. In a hello world, you might come out ahead in 1.7.x. Maybe 9000 is better?

cheald 11y ago
I wrote Manticore (https://github.com/cheald/manticore https://github.com/cheald/manticore) because of my dissatisfaction with Ruby HTTP clients under JRuby; it uses the Apache HTTPComponents (completely sidestepping Ruby's stdlib http/networking stuff) and is extremely fast. It might be worth looking into for you.
nirvdrum 11y ago
Do you have anything you can point at regarding String performance? Everything I've seen shows JRuby being faster than MRI. But I'm looking to see if we can make it even faster than it currently is. Any pathological cases would be incredibly helpful.
- ericb 11y ago
  I can send you an example. Can I drop you an email? I think also that we are friends on linkedin, coincidentally. I can message you there (if that is a useful way to get in touch?).
  - ericb 11y ago
    I sent an email to your email address at nirvdrum with what I've been looking at.
    - nirvdrum 11y ago
      I got it, thanks. And thanks for following up. I'll take a look and let you know what I find.

amalag 11y ago

You don't have to spawn a separate instance for each CPU core. Granted there are web servers that take care of some of that by having multiple workers.

juliangregorian 11y ago

If you need system-level bindings: no. If you use threading: yes.

headius 11y ago
What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.
- juliangregorian 11y ago
  Ok, then why do none of the C app servers work in JRuby?
  - cheald 11y ago
    Because the C extension API isn't supported. Or to put it another way, you can call C libraries from JRuby, but you can't write C that calls JRuby. If you want to do that, you would replace it with a Java extension, instead. It's possible to offer "native extensions" for both MRI and JRuby from a gem by providing both via C and Java extensions, though.