`[T]::partial_sort_unstable()` performance on short prefixes

One of the most common use cases for the new nightly [T]::partial_sort_unstable() (Tracking issue: #149046) is to sort the start of the slice, ..n.

I extensively benchmarked this vs. the heap-sort based partial_sort crate (v1.0.0).

Generally, it looks like std significantly outperforms the heap-based implementation, except on very short prefixes, where it is significantly slower. This goes more than 4x in either direction.

Is it clear why that happens? Can it be fixed without impacting overall performance?

Setup

Similar to https://github.com/Voultapher/sort-research-rs.

Data types:

• u64
• string: 10-byte String representation created from the u64
• kibibyte: 1 KiB on the stack, where the first 8 bytes are the u64

Scenarios:

• random: Uniform over full range
• random_z1: Zipf with exponent 1
• random_d20: Uniform over 0..20
• random_p5: 5% of elements uniform over full range, 95% fixed middle value
• random_p95: 95% of elements uniform over full range, 5% fixed middle value
• ascending: 0, 1, 2, 3, ...
• descending

Results on Zen 5: Speedup of partial_sort 1.0.0 over nightly-2026-01-15

Green: std is faster

Dashed lines at prefix sizes 1, 2, 4, 8, 16, 32, 64.

Code and raw data: https://github.com/niklasf/partial_sort_vendored_std

cc @sundy-li @tisonkun

Start with the benchmark code and raw data in the linked partial_sort_vendored_std repository, then inspect the nightly std implementation of [T]::partial_sort_unstable() for the ..n case. Reproduce the short-prefix comparisons across the listed data types and distributions. Done means identifying the cause and demonstrating a fix that improves short prefixes without reducing overall performance.