On 14/01/15 15:50, Peter Levart wrote:
Hi,
Loosely related to this topic, there is some local variable caching of
comparableClassFor() result already being performed inside
iterative/recursive methods of TreeNode, but this caching is just
positive caching, meaning that null return is not cached. For keys that
happen to implement Comparable, but are not simple-self-comparable
(their class is not of the form: class C implements Comparable<C>),
reflection is invoked each time comparison of the search key with Node
key is attempted. This can be improved:
http://cr.openjdk.java.net/~plevart/jdk9-dev/HM.comparableClassFor/InCallNegativeCache/webrev.01/
This seems like a good change.
-Chris
Using modified version of Bernd's benchmark (adding 3rd variant of keys
- FalseComp):
http://cr.openjdk.java.net/~plevart/jdk9-dev/HM.comparableClassFor/InCallNegativeCache/HashMapCollision.java
...and and only running for badHash shows almost 25% improvement for
FalseComp keys (skipping reflection invocations) and barely measurable
improvement for NoComp keys (skipping instanceof checks), while Comp
keys are not affected.
Original JDK9 HashMap:
Benchmark (initialSize) Mode Samples
Score Error Units
j.t.HashMapCollision.badDistFalseComp 16 ss 20 4221.438
+- 250.774 ms
j.t.HashMapCollision.badDistNoComp 16 ss 20 2868.605
+- 40.754 ms
j.t.HashMapCollision.badDistWithComp 16 ss 20 3030.780
+- 111.315 ms
Patched:
Benchmark (initialSize) Mode Samples
Score Error Units
j.t.HashMapCollision.badDistFalseComp 16 ss 20 3237.953
+- 143.608 ms
j.t.HashMapCollision.badDistNoComp 16 ss 20 2643.024
+- 137.067 ms
j.t.HashMapCollision.badDistWithComp 16 ss 20 3087.902
+- 122.041 ms
Regards, Peter
