Performance of generic tupes

[nicolasstucki]

Compiling

(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22).tail

is 5X faster that compiling

(1 *: 2 *: 3 *: 4 *: 5 *: 6 *: 7 *: 8 *: 9 *: 10 *: 11 *: 12 *: 13 *: 14 *: 15 *: 16 *: 17 *: 18 *: 19 *: 20 *: 21 *: 22 *: ()).tail

70.956 ±(99.9%) 0.702 ms/op [Average]
  (min, avg, max) = (69.699, 70.956, 72.428), stdev = 0.809

vs

360.557 ±(99.9%) 8.647 ms/op [Average]
  (min, avg, max) = (348.357, 360.557, 384.038), stdev = 9.958

[OlivierBlanvillain]

How does it look without the .tail?

[nicolasstucki]

Does not change much. I did some experiments and it looks like the performance loss depends on the amount on generated code and the number of cases in inline matches.

[milessabin]

It'd be worth doing some benchmarks against the equivalents using nested pairs rather than tuples. They're almost certainly going to win for things like head and tail, but it'd be useful to see how they compare for other types of operation.

[nicolasstucki]

We should benchmark both the compilation time and runtime

[liufengyun]

The regressional benchmark is still running (begins from last November, with one test every 5 PR merges):

http://dotty-bench.epfl.ch/ (at the bottom)

Once it finishes, we will be able to locate to the specific PR that causes the 2x slow down for generic tuples.