https://bruceediger.com/posts/mergesort-investigation-1/
It seems that adding one node to a linked list causes a repeatable performance drop. That is, linked lists of say 2^21 nodes sort faster than lists of 2^21 + 1 nodes.
1) at/around powers of two
2) regardless whether using GC or preallocating
The jumps in your measurements could be related to the cache hierarchy. On Linux (probably macOS too) you should be able to run "perf stat ./mergesort" to show you the hitrate of your CPU's caches.
I'd be interested in a follow-up post :)
The linked list nodes are 16 bytes, and both 8-byte fields (.Next and .Data) get read and written during sorting. Up to a point, larger node sizes,which I would thing would change caching, don't change where the performance drops occur: https://bruceediger.com/posts/mergesort-investigation-7/
Sorting an already sorted, or reverse sorted list, doesn't exhibit the performance drops either: https://bruceediger.com/posts/mergesort-investigation-9/
A purely recursive mergesort doesn't show the performance drops: https://bruceediger.com/posts/mergesort-investigation-3/
The code only uses standard Go packages. I wrote the linked list struct, I'm not using a package's struct or code. I don't even use standard package code during sorting, only in timing and list preparation.
What you suggest may be true, but it seems very unlikely.
A C-transliteration of my original Go algorithm shows similar overall performance, with performance drops at the same list lengths.
Forcing garbage collection right after each sort (releasing all references to the sorted linked list) didn't change anything, either: https://bruceediger.com/posts/mergesort-investigation-10/