Benchmarks
Sorting random, uniformly distributed values.
These results are for radsort::unopt::sort. Unlike radsort::sort, the unopt version sorts the slice by all bytes of the key, not only the ones which differ between the keys, so the charts below can be considered worst-case.
High times per element when sorting short slices are caused by a constant overhead per byte of the key (calculating bucket offsets and verifying that key mapping did not change during sorting). The total running time does not change much for short slices, the constant overhead just gets spread between a growing number of elements.
As with all benchmarks, take these with a grain of salt and run your own to see how radsort behaves in your use case.
Benchmarked with Criterion on Windows 10, i7-8750H @ 2.2 GHz (disabled Turbo Boost)
Jump to: u8/i8 | u16/i16 | u32/i32 | u64/i64 | u128/i128 | f32 | f64
