diff --git a/src/liballoc/slice.rs b/src/liballoc/slice.rs
index 2b4ce9fe49c8e..68f2313843c31 100644
--- a/src/liballoc/slice.rs
+++ b/src/liballoc/slice.rs
@@ -1306,10 +1306,6 @@ impl<T> [T] {
     /// This sort is stable (i.e. does not reorder equal elements) and `O(m n log(m n))`
     /// worst-case, where the key function is `O(m)`.
     ///
-    /// For expensive key functions (e.g. functions that are not simple property accesses or
-    /// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be
-    /// significantly faster, as it does not recompute element keys.
-    ///
     /// When applicable, unstable sorting is preferred because it is generally faster than stable
     /// sorting and it doesn't allocate auxiliary memory.
     /// See [`sort_unstable_by_key`](#method.sort_unstable_by_key).
@@ -1496,10 +1492,6 @@ impl<T> [T] {
     /// randomization to avoid degenerate cases, but with a fixed seed to always provide
     /// deterministic behavior.
     ///
-    /// Due to its key calling strategy, [`sort_unstable_by_key`](#method.sort_unstable_by_key)
-    /// is likely to be slower than [`sort_by_cached_key`](#method.sort_by_cached_key) in
-    /// cases where the key function is expensive.
-    ///
     /// # Examples
     ///
     /// ```