Hacker News Reader

Comment by gary4gar | Hacker News Reader

is it faster than MRI?

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.

We'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.

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.

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.

For things like Rails, that are going to be running all the time, does the JVM warm up time really matter?

No, its just a drag to TDD with.

I 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.

That's what we do as well. It works well enough.

provided you final build, tests and do some sanity checking under JRuby, it should surely meet most needs?

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/

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.

50,000 requests aren't enough for the JIT to warm up?

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.

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.

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.

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/).

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.

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 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.

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.

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 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.

FWIW, I've never had any luck with Theine or Drip. But --dev is good stuff - it basically turns off the JIT and invokedynamic, which are great for long-running processes but not that useful for shorter script runs or consoles. JRuby defaults to "good for long-running processes" mode, which is great for production but less useful when running short-lived tasks.

Yeah, certainly understood WRT JDBC. But, as nirvdrum pointed out elsewhere in the thread, you might look at Sequel rather than AR if you do want to do JRuby stuff and AR-JDBC is holding you back - it's well-supported and I know lots of folks use it well.

The domain sockets thing is unfortunate, but AFAIK, they just aren't supported by JDBC.

I realized that PostgreSQL can listen to both the Unix domain socket and a TCP address so I've been able to run the tests. I'm stuck now with the integration tests failing because they can't run the Selenium Chrome webdriver. I opened an issue. I also have some failed tests on a model, still didn't looked at them.

I won't convert this app to Sequel only to check that it works with JRuby. Neither I'll write the next one with Sequel. If JRuby doesn't handle AR it's over for me. It's JRuby that must be compatible with MRI (the reference implementation of the language), not the other way around. That until the majority of rubyists use JRuby as default. It's too risky.

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?

I wrote 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.

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.

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?).

I sent an email to your email address at nirvdrum with what I've been looking at.

I got it, thanks. And thanks for following up. I'll take a look and let you know what I find.

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=... .

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.

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.

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

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.

Ok, then why do none of the C app servers work in JRuby?

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.

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

> That does not mean I use it for production.

Any particular reason why? (I'm just curious, I do absolutely nothing with ruby)

True in the 1.8 1.9 era. Against 2.2 it is not an automatic "Is faster"

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.

Reply on news.ycombinator.com