It does require an instance per pair and it forces...

# announcements

[karelpeeters]

It does require an instance per pair and it forces the values to be boxed. A real primitve array will be way faster.

[ilya.gorbunov]

Or a specialized pair of two longs:
data class PairLong(val a: Long, val b: Long)

[karelpeeters]

Benchmark: https://gist.github.com/flaghacker/233297afc8c5e6b785e521dafdf6ffd8

[karelpeeters]

General Pair and PairLong are about the same,/withing margin of error, a flattened array is way faster.

[karelpeeters]

Maybe I made a mistake somewhere? The result is quite surprising.

[bissell]

all the 0ms runtimes make me wonder if the compiler figured out how to precompute sum without running the loop on the flattened array

[bissell]

might try writing the same set of random values to each of the arrays

[karelpeeters]

Well the compiler definitely didn't (looking at the bytecode) but yes, the JIT might have.

[bissell]

hahah yeah I hope no one's been spending time putting optimizations like that in kotlinc 😉

[karelpeeters]

I'll try writing a proper JMH benchmark tomorrow, using BlackHole etc.

[bissell]

tbh even without precomputation it wouldn't surprise me to see the flattened array perform a lot better just because of the more compact memory footprint. The plain generic Pair beating the specialized version is the more curious result to me

[karelpeeters]

Beating is a strong word, I'd say they're about equal from a couple of runs.

[karelpeeters]

Still strange.

[bissell]

ah ok

[bissell]

yeah you'd still think it might consistently outperform without the boxing

[gildor]

I wouldn’t recommend to use result of those benchmarks for anything, without proper test harness it’s just useless

[ilya.gorbunov]

@karelpeeters To be fair the author asked about the difference between a LongArray of two longs and a Pair. And in the benchmark all LongArray pairs are flattened into one array.