While working on another issue, I get these results JRuby file reading microbenchmarks · GitHub in which it appears the JRuby
1.6.5/Oracle Java (client mode) 1.7.0_01 combo is slower than JRuby
1.6.3/1.6.0_26 when doing (3) reads on a 500,000 LF delimited test file.
On Win7 I see 6.24s (user+system) vs 2.025s when doing binary reads, and
7.769s vs. 3.102s when doing text reads.
Results also provided for JRuby 1.6.5/1.7.0_01 on Arch Linux running in
a VirtualBox VM on Win7. The results are similar to the Windows results.
Sadly I did not run JRuby 1.6.3/1.6.0_26 on Arch back in July.
I’m focused on the other issue, but am interested in what others are
seeing with the JRuby 1.6.5/1.7.0_01 combination as well as whether the
microbenchmarks are flawed for what they’re trying to measure.
running in a VirtualBox VM on Win7. The results are similar to the
Windows results. Sadly I did not run JRuby 1.6.3/1.6.0_26 on Arch
back in July.
I’m focused on the other issue, but am interested in what others
are seeing with the JRuby 1.6.5/1.7.0_01 combination as well as
whether the microbenchmarks are flawed for what they’re trying to
measure.
Try -Xinvokedynamic.invocation.switchpoint=false for Java SE 7GA or
7u1. I heard from Charles that there’s a known degradation about
method invocation optimization. ‘Degradation in GA’ may sound funny
though
Here’s my result with/without switchpoint.
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
While working on another issue, I get these results JRuby file reading microbenchmarks · GitHub in which it appears the JRuby 1.6.5/Oracle Java
(client mode) 1.7.0_01 combo is slower than JRuby 1.6.3/1.6.0_26 when doing (3)
reads on a 500,000 LF delimited test file.
On Win7 I see 6.24s (user+system) vs 2.025s when doing binary reads, and 7.769s
vs. 3.102s when doing text reads.
Results also provided for JRuby 1.6.5/1.7.0_01 on Arch Linux running in a
VirtualBox VM on Win7. The results are similar to the Windows results. Sadly I did
not run JRuby 1.6.3/1.6.0_26 on Arch back in July.
I’m focused on the other issue, but am interested in what others are seeing with
the JRuby 1.6.5/1.7.0_01 combination as well as whether the microbenchmarks are
flawed for what they’re trying to measure.
Hmm, that’s an interesting finding. I would normally be more inclined
to suspect a regression in JRuby rather than in the JDK. Are you able
to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).
If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.
WRT Nahi’s suggestion about invokedynamic…that doesn’t come into
play here JRuby 1.6.x does not use invokedynamic at all. You aren’t
running JRuby master/1.7, right?
to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).
If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.
I’ll swing back, install 1.6.3 and update the gist.
Updates at JRuby file reading microbenchmarks · GitHub and it
appears to be a 1.6.5 perf regression as 1.6.3 (Win7) on 1.7.0_01
appears similar (maybe a scooch faster?) to 1.6.3 on 1.6.0_26.
to run 1.6.3 on Java 1.7.0_01? (your results only seem to show JRuby
1.6.5 on Java 1.7.0_01).
If it also happens with JRuby 1.6.3, then we could look into what
might have regressed in the JDK itself to slow down IO. If it’s JRuby,
we can look there.
I’ll swing back, install 1.6.3 and update the gist.
WRT Nahi’s suggestion about invokedynamic…that doesn’t come into
play here JRuby 1.6.x does not use invokedynamic at all. You aren’t
running JRuby master/1.7, right?
I’ll build JRuby master on Windows and post thost results too. Assuming
I have ant and javac on PATH, its rvm install jruby-head on Linux,
right?
