Startup time degradation vs 1.5.x - expected?

Ruby JRuby
1

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

2

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.

3

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:)