Skip to content

Commit 317f153

Browse files
committed
Revert "Remove mentions of unstable sort_by_cached key from stable documentation"
This reverts commit 9c7b69e.
1 parent 3777b86 commit 317f153

File tree

2 files changed

+8
-0
lines changed

2 files changed

+8
-0
lines changed

src/liballoc/slice.rs

+4
Original file line numberDiff line numberDiff line change
@@ -257,6 +257,10 @@ impl<T> [T] {
257257
/// This sort is stable (i.e., does not reorder equal elements) and `O(m n log(m n))`
258258
/// worst-case, where the key function is `O(m)`.
259259
///
260+
/// For expensive key functions (e.g. functions that are not simple property accesses or
261+
/// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be
262+
/// significantly faster, as it does not recompute element keys.
263+
///
260264
/// When applicable, unstable sorting is preferred because it is generally faster than stable
261265
/// sorting and it doesn't allocate auxiliary memory.
262266
/// See [`sort_unstable_by_key`](#method.sort_unstable_by_key).

src/libcore/slice/mod.rs

+4
Original file line numberDiff line numberDiff line change
@@ -1563,6 +1563,10 @@ impl<T> [T] {
15631563
/// randomization to avoid degenerate cases, but with a fixed seed to always provide
15641564
/// deterministic behavior.
15651565
///
1566+
/// Due to its key calling strategy, [`sort_unstable_by_key`](#method.sort_unstable_by_key)
1567+
/// is likely to be slower than [`sort_by_cached_key`](#method.sort_by_cached_key) in
1568+
/// cases where the key function is expensive.
1569+
///
15661570
/// # Examples
15671571
///
15681572
/// ```

0 commit comments

Comments
 (0)