Hi Matthias,
On 2017-10-10 18:23, Baesken, Matthias wrote:
Hi Claes, to me it looks like the old jdk8 coding is not slower than the
jdk9/10 coding .
a simple and somewhat naïve JMH benchmark to assess performance:
http://cr.openjdk.java.net/~redestad/scratch/ZipUtils.java
I've benchmarked the code I proposed to fall back to, adding a variant
to do some
quick sanity checking to avoid exceptional control flow on common mal-formed
cases (dosToJavaTime9Bench2), and can show it doesn't hurt performance
too much:
Benchmark (dosTime) Mode Cnt Score Error
Units
ZipUtils.dosToJavaTime8Bench 677456332112 thrpt 10 3.723 ± 0.103
ops/us
ZipUtils.dosToJavaTime9Bench 677456332112 thrpt 10 15.207 ± 0.540
ops/us
ZipUtils.dosToJavaTime9Bench2 677456332112 thrpt 10 14.241 ± 1.193
ops/us
As I recalled it's about a 4x difference.
Running this benchmark with more threads (4) shows that the JDK 8 impl
hides a
scalability issue (Date() uses a shared calendar object, with
synchronization to keep
it thread safe):
Benchmark (dosTime) Mode Cnt Score Error
Units
ZipUtils.dosToJavaTime8Bench 677456332112 thrpt 10 1.441 ± 0.112
ops/us
ZipUtils.dosToJavaTime9Bench 677456332112 thrpt 10 53.166 ± 0.886
ops/us
ZipUtils.dosToJavaTime9Bench2 677456332112 thrpt 10 52.238 ± 0.865
ops/us
We can see that we're slightly worse on the odd corner case of dosTime=0:
Benchmark (dosTime) Mode Cnt Score Error Units
ZipUtils.dosToJavaTime8Bench 0 thrpt 10 40.069 ± 0.719 ops/us
ZipUtils.dosToJavaTime9Bench 0 thrpt 10 2.177 ± 0.032 ops/us
ZipUtils.dosToJavaTime9Bench2 0 thrpt 10 33.439 ± 0.842 ops/us
... but a naïve variant testing mixed valid/invalid inputs shows we're
still much better
off with dosToJavaTime9Bench2:
Benchmark (dosTime) (dosTime2) Mode
Cnt Score Error Units
ZipUtilsMixed.dosToJavaTime8Bench 677456332112 0 thrpt
5 1467.281 ± 328.030 ops/ms
ZipUtilsMixed.dosToJavaTime9Bench 677456332112 0 thrpt 5
24412.943 ± 1151.896 ops/ms
ZipUtilsMixed.dosToJavaTime9Bench2 677456332112 0 thrpt 5
20687.981 ± 1535.571 ops/ms
http://cr.openjdk.java.net/~redestad/scratch/ZipUtilsMixed.java
Finally we can see that we're generally faster in interpreted mode (this
code is of
general interest to startup on many internal startup benchmarks):
Benchmark (dosTime) Mode Cnt Score Error
Units
ZipUtils.dosToJavaTime8Bench 677456332112 thrpt 5 152.447 ±
5.899 ops/ms
ZipUtils.dosToJavaTime9Bench 677456332112 thrpt 5 263.718 ±
19.450 ops/ms
ZipUtils.dosToJavaTime9Bench2 677456332112 thrpt 5 266.059 ±
5.003 ops/ms
I'll send out a RFR for an implementation similar to the
dosToJavaTime9Bench2
experiment soon, so that we can be both backwards compatible and avoid
scalability bottlenecks.
Thanks!
/Claes
