diff options
| author | bors <bors@rust-lang.org> | 2015-10-30 22:23:41 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2015-10-30 22:23:41 +0000 |
| commit | 64b027764302aa67aa701a9f81bd938ca3d4052a (patch) | |
| tree | 99fc863475771ccdf0a411c6e9ac9ceb3f9c483f /src/libstd/sys/unix/stack_overflow.rs | |
| parent | cc8d398e28b6b1918ef85479c2d040dfd0fe582d (diff) | |
| parent | 46068c9dafe8cfa763ef855ec21f577a1e058de1 (diff) | |
| download | rust-64b027764302aa67aa701a9f81bd938ca3d4052a.tar.gz rust-64b027764302aa67aa701a9f81bd938ca3d4052a.zip | |
Auto merge of #29454 - stepancheg:vec-reserve, r=bluss
Before this patch `reserve` function allocated twice as requested
amount elements (not twice as capacity). It leaded to unnecessary
excessive memory usage in scenarios like this:
```
let mut v = Vec::new();
v.push(17);
v.extend(0..10);
println!("{}", v.capacity());
```
`Vec` allocated 22 elements, while it could allocate just 11.
`reserve` function must have a property of keeping `push` operation
cost (which calls `reserve`) `O(1)`. To achieve this `reserve` must
exponentialy grow its capacity when it does reallocation.
There's better strategy to implement `reserve`:
```
let new_capacity = max(current_capacity * 2, requested_capacity);
```
This strategy still guarantees that capacity grows at `O(1)` with
`reserve`, and fixes the issue with `extend`.
Patch imlpements this strategy.
Diffstat (limited to 'src/libstd/sys/unix/stack_overflow.rs')
0 files changed, 0 insertions, 0 deletions
