diff options
| author | bors <bors@rust-lang.org> | 2016-09-26 04:38:18 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2016-09-26 04:38:18 -0700 |
| commit | 3bf4a7ad45bceef2e7ac666f4cbb41a37d6af763 (patch) | |
| tree | e14c410297bb5a0deb14471046b46853354262f9 /src/libstd/sys/unix/net.rs | |
| parent | b786976a158e79196254f489bb3a6f87e4d16a5a (diff) | |
| parent | 4eb069c9811bc25d6ef9413de6058e5f14707816 (diff) | |
| download | rust-3bf4a7ad45bceef2e7ac666f4cbb41a37d6af763.tar.gz rust-3bf4a7ad45bceef2e7ac666f4cbb41a37d6af763.zip | |
Auto merge of #36734 - nnethercote:fix-HashSet-sizing, r=Aatch
Don't allocate during default HashSet creation. The following `HashMap` creation functions don't allocate heap storage for elements. ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This is good, because it's surprisingly common to create a HashMap and never use it. So that case should be cheap. However, `HashSet` does not have the same behaviour. The corresponding creation functions *do* allocate heap storage for the default number of non-zero elements (which is 32 slots for 29 elements). ``` HashMap::new() HashMap::default() HashMap::with_hasher() ``` This commit gives `HashSet` the same behaviour as `HashMap`, by simply calling the corresponding `HashMap` functions (something `HashSet` already does for `with_capacity` and `with_capacity_and_hasher`). It also reformats one existing `HashSet` construction to use a consistent single-line format. This speeds up rustc itself by 1.01--1.04x on most of the non-tiny rustc-benchmarks.
Diffstat (limited to 'src/libstd/sys/unix/net.rs')
0 files changed, 0 insertions, 0 deletions
