[jruby-user] startup time degradation vs 1.5.x - expected?

[Gergely Nagy]

HNY all,

After upgrading an old -embedded- Jruby setup, I noticed the startup time is ~2x slower with 1.7.9 than 1.5.x.

I have started some java profiling (will provide details if anyone interested), but before I dig deeper- I'd love to hear from the community: is this degration known/expected, and is there an easy workaround?

Note: I'm aware of the startup performance being an age old problem with Jruby, I was just a bit puzzled that it got that much worse since the old version.

Also saw Charlie's excellent article, http://blog.headius.com/2010/03/jruby-startup-time-tips.html , tried to adapt a few of the tricks to the embedded context, without groundbraking results yet. Switching off JIT didn't help in my case.

The reason I'm badly hit by this now is that the production code currently spins up Jruby several times- I know I'd have work on avoiding that (eg. caching the runtimes), maybe using some other LocalContextProvider, etc.. but I was hoping to cross that bridge later, after a smooth Jruby update.

I'd be really grateful for any more pointers or ideas for workarounds.

Thanks, Gergo

[Eric West]

you didn't mention which java you are using. my understanding is that jruby has been optimized for 1.7, with invoke_dynamic available, along with a handful of other factors.  I'm also wondering about whether other aspects of your setup, such as any flags passed to either JRuby or the JVM could be the culprit here.

I haven't heard anything about a huge startup increase from 1.5 to 1.7, but I've really only been using JRuby since 1.6.5 or so, others may have noticed or heard something.

My best guess would be that something has changed in what is optimized for, or something like that, and so something about your code, env or config/setup was optimal on 1.5 and is sub-optimal on 1.7. Just throwing this out there in the hopes I spur some ideas or further help from the community.

[Gergely Nagy]

something about your code, env or config/setup was optimal on 1.5 and is sub-optimal on 1.7. Just throwing this out there in the hopes I spur some ideas or further help from the community.

Yes, this sounds plausible. Thanks.

you didn't mention which java you are using. 

 

Yeah, sorry for leaving out some necessary details.. in fact I had them pasted here, but then I decided to cut it down to a minimum and check if there is a known generic perf regression from Jruby's standpoint.

Anyway..for a trimmed down profiling session I just used this main method on JRE1.6.0_26-b03 -server:

        ScriptingContainer c = new ScriptingContainer();

        c.setCompatVersion(CompatVersion.RUBY1_8);

        c.setObjectSpaceEnabled(false);

        // c.setCompileMode(CompileMode.OFF);  // experimented with this

        c.runScriptlet("puts 'Hello'");

In my environment, this method takes 4.1s  and 7.7s  with 1.5.6 and 1.7.9 respectively.

According to YourKit, it's due mostly due to org.jruby.Ruby.init() slowdown 3.1s -> 6.2s. 

It seems to be the LoadService is doing much more now - eg, LoadService.require() is invoked 20 times now (up from 2), and takes 5x more time (0.5s to 2.5s). In my production code, I have a lot more require()s of course and a lot of class lookups, I'm wondering if they are impacted even more..anyway, this 2x overall slowdown seems to be the same in the real life context too.

Yes, it's still 1.8 mode - I have to keep it like that I'm afraid due to external dependencies..Anyway 1.9 mode seems even slower (around 2-3x slowdown).

my understanding is that jruby has been optimized for 1.7, with invoke_dynamic available

I just tried to pass this -Xcompile.invokedynamic=true to the JVM it actually seemed to slow down the above even more.

Again, my case may be special as I have many smaller embedded scripts rather than massive processing that be better helped by JIT warmup etc.. 

I just want those little scripts loaded as fast as possible - at least not slower than 1.5.6.

Thank you for any hints and just your patience:)