Hi,
java.lang.Objects.hash is convenient, however, it does result in memory
allocation for varargs.
In practice, it can easily be visible in the benchmarks (at least for Java
1.8), so I suggest we create our own API
and use it instead of java.util.Objects#hash
We can have "up to 10 overloads" (or whatever we need), so the hashcode
won't need to allocate arrays.
If no objections within a week or so, I will commit that fix, and I would
add `java.util.Objects#hash` to the list of forbidden APIs.
I'm ok if somebody else wants to pick this.
---
Sample with a4fa05458840cfd:
@Benchmark
public RexNode baseline_eq() {
return rex.makeCall(
SqlStdOperatorTable.EQUALS,
rex.makeInputRef(intType, 0),
rex.makeInputRef(intType, 1));
}
@Benchmark
public int equals(Blackhole blackhole) {
RexNode node = rex.makeCall(
SqlStdOperatorTable.EQUALS,
rex.makeInputRef(intType, 0),
rex.makeInputRef(intType, 1));
blackhole.consume(node);
return node.hashCode();
}
...
Benchmark Mode Cnt Score Error Units
baseline_equals avgt 5 222 ± 121 ns/op
equals avgt 5 248 ± 68 ns/op
greater_than avgt 5 275 ± 54 ns/op
less_than avgt 5 224 ± 27 ns/op
baseline_equals:·gc.alloc.rate.norm avgt 5 496 ± 0 B/op
equals:·gc.alloc.rate.norm avgt 5 568 ± 0 B/op
greater_than:·gc.alloc.rate.norm avgt 5 624 ± 0 B/op
less_than:·gc.alloc.rate.norm avgt 5 520 ± 0 B/op
Vladimir
