Skip to content

Commit 39dc315

Browse files
the8472cuviper
andcommitted
Apply suggestions from code review
Co-authored-by: Josh Stone <cuviper@gmail.com>
1 parent c780fe6 commit 39dc315

File tree

1 file changed

+11
-12
lines changed

1 file changed

+11
-12
lines changed

library/alloc/src/vec/mod.rs

+11-12
Original file line numberDiff line numberDiff line change
@@ -2788,7 +2788,7 @@ impl<T, I: SliceIndex<[T]>, A: Allocator> IndexMut<I> for Vec<T, A> {
27882788
///
27892789
/// # Allocation behavior
27902790
///
2791-
/// In general `Vec` does not guarantee any particular grow/allocation stategy.
2791+
/// In general `Vec` does not guarantee any particular growth or allocation strategy.
27922792
/// That also applies to this trait impl.
27932793
///
27942794
/// **Note:** This section covers implementation details and is therefore exempt from
@@ -2798,29 +2798,28 @@ impl<T, I: SliceIndex<[T]>, A: Allocator> IndexMut<I> for Vec<T, A> {
27982798
/// depending on the supplied iterator:
27992799
///
28002800
/// * preallocate based on [`Iterator::size_hint()`]
2801-
/// * and panic if the number of items is not outside the provided lower/upper bounds
2801+
/// * and panic if the number of items is outside the provided lower/upper bounds
28022802
/// * use an amortized growth strategy similar to `pushing` one item at a time
28032803
/// * perform the iteration in-place on the original allocation backing the iterator
28042804
///
28052805
/// The last case warrants some attention. It is an optimization that in many cases reduces peak memory
2806-
/// consumption and improves cache locality. But when a large number of big, short-lived
2807-
/// allocations are created, only a small fraction of their items gets collected, no further use
2808-
/// is made of the spare capacity and the resulting `Vec` is moved into a longer-lived structure
2809-
/// this can lead to the large allocations having their lifetimes unnecessarily extended which
2810-
/// can result in increased memory footprint.
2806+
/// consumption and improves cache locality. But when big, short-lived allocations are created,
2807+
/// only a small fraction of their items get collected, no further use is made of the spare capacity
2808+
/// and the resulting `Vec` is moved into a longer-lived structure, then this can lead to the large
2809+
/// allocations having their lifetimes unnecessarily extended which can result in increased memory
2810+
/// footprint.
28112811
///
2812-
/// In cases where this is an issue the excess capacity can be discard with [`Vec::shrink_to()`],
2813-
/// [`Vec::shrink_to_fit()`] or by collecting into [`Box<[T]>`][owned slice] instead which additionally reduces
2814-
/// the size of the longlived struct.
2812+
/// In cases where this is an issue, the excess capacity can be discarded with [`Vec::shrink_to()`],
2813+
/// [`Vec::shrink_to_fit()`] or by collecting into [`Box<[T]>`][owned slice] instead, which additionally reduces
2814+
/// the size of the long-lived struct.
28152815
///
28162816
/// [owned slice]: Box
28172817
///
28182818
/// ```rust
28192819
/// # use std::sync::Mutex;
28202820
/// static LONG_LIVED: Mutex<Vec<Vec<u16>>> = Mutex::new(Vec::new());
28212821
///
2822-
/// // many short-lived allocations
2823-
/// for i in 0..100 {
2822+
/// for i in 0..10 {
28242823
/// let big_temporary: Vec<u16> = (0..1024).collect();
28252824
/// // discard most items
28262825
/// let mut result: Vec<_> = big_temporary.into_iter().filter(|i| i % 100 == 0).collect();

0 commit comments

Comments
 (0)