TRMC implementation of @

[yallop]

A tail-recursive-modulo-cons implementation of Stdlib.(@) (and List.append), replacing the existing stack-consuming implementation.

To avoid a slowdown over the existing version, the function is also unrolled. (It's worth noting, though, that this isn't the fastest possible implementation: an unrolled stack-consuming version would be even faster.)

Benchmark results:

Almost always faster than the current implementation; always faster on lists of length less than 16384; twice as fast on long lists

l1 length	original	trmc	trmc/unrolled
1	6.46ns	9.74ns	5.47ns
2	9.25ns	14.58ns	7.56ns
4	16.58ns	24.49ns	13.76ns
8	28.55ns	43.67ns	22.30ns
16	61.44ns	84.18ns	55.11ns
32	131.71ns	151.22ns	102.34ns
64	250.58ns	286.24ns	197.16ns
128	511.47ns	596.78ns	382.34ns
256	1_046.92ns	1_222.15ns	804.63ns
512	2.93us	2.75us	1.79us
1024	6.36us	5.84us	3.96us
2048	14.37us	12.96us	9.38us
4096	33.32us	31.76us	23.32us
8192	79.70us	82.88us	67.22us
16384	240.20us	246.96us	226.37us
32768	776.65us	870.93us	796.78us
65536	2.84ms	3.02ms	2.76ms
131072	9.16ms	8.45ms	7.79ms
262144	23.33ms	18.02ms	16.17ms
524288	59.84ms	36.45ms	34.23ms
1048576	155.05ms	80.61ms	75.15ms

[dbuenzli]

Looks good to me. If you are in the mood I left a few suggestions to improve the docs.

[gasche]

always faster on lists of length less than 16384

A minor point: if you observe a slowdown with TMC functions on semi-large lists, it is probably caused by the benchmarking setup. In the regime where the list length is close to the minor heap size, you can observe artifical promotion effects. See the "Promotion" section of #9760 (comment). In short: if you are "ignoring" the result of the function call in your benchmark, you should store it into a long-lived reference instead for more realistic promotion behavior (in general, the result of operations on very large inputs do stay alive until after the next minor collection).

[yallop]

@gasche:

In short: if you are "ignoring" the result of the function call in your benchmark, you should store it into a long-lived reference instead for more realistic promotion behavior

Thanks for the suggestion. I tried this and now the benchmark shows that the new version is always at least a smidgen faster than the existing implementation.

[nojb]

LGTM

[nojb]

This looks good to go, but still needs a second official approval. Perhaps @gasche can do the honours?

[nojb]

@yallop: do you mind if I squash-merge your PR? I normally squash-merge small PRs as it is easier to cherry-pick them, revert them, etc, but since you took care to have a clean history, perhaps you have a preference for doing a plain merge...

[yallop]

Thanks for asking, @nojb! I'm happy to have it squash-merged.

[nojb]

Thanks for asking, @nojb! I'm happy to have it squash-merged.

Thanks, merged!