Sorts Span<T>
and T[]
more quickly than Array.Sort
. It's around 45% faster in serial mode, and upto a core-count-based parallelisation speedup for large arrays, though details matter: it's no faster for strings, just 20% faster for integral builtins, but more than 100% faster for structs with custom orderings.
Usage:
IOrdering
with a struct, which defines a LessThan
method to compare to elements.someSpan.WithOrder(new MyOrdering()).Sort()
, which uses an insertion sort for small arrays, quicksort for medium size arrays, and parallel quick sort for large arrays.someArray.AsSpan(start, length)
extension method in System.Memory that makes
slicing really easy.someSpan.WithIComparableOrder().Sort()
, which is often no slower, and thereby avoid implementing IOrdering<T>
. This uses efficient special-cased orderings for common types like double
or int
..Sort()
are implemented as extension
methods in the Anoprsst.Uncommon
namespace, include a merge sort (stable, without implausible O(N2) behavior) and a serial quick sort.In terms of performance: Anorpsst's QuickSort outperforms Array.Sort in all cases I tried. The difference is small for large arrays of primitive types such as an int
(Array.Sort: 64.1 ns/item vs. QuickSort: 56.8 ns/item, ParallelQuickSort 10.3 ns/item), considerably larger for reference types (203 vs. 140 vs. 34.5 ns/item) and structs (147 vs. 88.1 vs. 16.3 ns/item). Smaller arrays/spans benefit more, such as for arrays of ints of approximately 128 elements: (Array.Sort: 17.861 ns/item vs. QuickSort: 13.373 ns/item, ParallelQuickSort 13.786 ns/item). All measurements done on .net core2.2; Custom IComparable implementations are particularly slow on the full .net framework, making the performance advantages particularly stark on the .net framework.
Feedback; PRs; bug reports; questions or plain cheers & jeers: please post in the issues on github.