+1
I am not sure the difference will be observable in real Calcite application,
because object allocation in Java is pretty efficient. But it is always good to
avoid unnecessary object allocation and reduce GC pressure if we can achieve it
easily.
On 2020/07/17 09:36:06, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote:
> 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
>
