|
79 | 79 | //! see each type's documentation, and note that the names of actual methods may
|
80 | 80 | //! differ from the tables below on certain collections.
|
81 | 81 | //!
|
82 |
| -//! ## Conventions |
83 | 82 | //! Throughout the documentation, we will adhere to the following conventions for
|
84 | 83 | //! operation notation:
|
85 | 84 | //!
|
|
89 | 88 | //! * Operations which have an *amortized* cost are suffixed with a `*`.
|
90 | 89 | //! * Operations with an *expected* cost are suffixed with a `~`.
|
91 | 90 | //!
|
92 |
| -//! ### Amortized Costs |
93 |
| -//! |
94 | 91 | //! Calling operations that add to a collection will occasionally require a
|
95 | 92 | //! collection to be resized - an extra operation that takes *O*(*n*) time.
|
96 | 93 | //!
|
97 |
| -//! Amortized costs are calculated to account for the time cost of this resize |
98 |
| -//! *over a sufficiently large series of operations*. An individual operation |
99 |
| -//! may be slower or faster due to the sporadic nature of collection resizing, |
100 |
| -//! however the average cost per operation will eventually equal the amortized |
101 |
| -//! cost. |
| 94 | +//! *Amortized* costs are calculated to account for the time cost of such resize |
| 95 | +//! operations *over a sufficiently large series of operations*. An individual |
| 96 | +//! operation may be slower or faster due to the sporadic nature of collection |
| 97 | +//! resizing, however the average cost per operation will eventually equal the |
| 98 | +//! amortized cost. |
102 | 99 | //!
|
103 | 100 | //! Rust's collections never automatically shrink, so removal operations aren't
|
104 | 101 | //! amortized.
|
105 | 102 | //!
|
106 |
| -//! ### Expected Costs |
107 |
| -//! |
108 |
| -//! [`HashMap`] uses expected costs to denote that it is theoretically possible, |
| 103 | +//! [`HashMap`] uses *expected costs to denote that it is theoretically possible, |
109 | 104 | //! though very unlikely, for [`HashMap`] to experience worse performance than
|
110 | 105 | //! the expected cost. This is due to the probablilistic nature of hashing -
|
111 | 106 | //! i.e. it is possible to generate a duplicate hash given some input key that
|
|
0 commit comments