Skip to content

Optimize Vec::shrink_to_fit() #21401

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 26, 2015
Merged

Conversation

lilyball
Copy link
Contributor

Don't reallocate when capacity is already equal to length

Vec::shrink_to_fit() may be called on vectors that are already the
correct length. Calling out to reallocate() in this case is a bad idea
because there is no guarantee that reallocate() won't allocate a new
buffer anyway, and based on performance seen in external benchmarks, it
seems likely that it is in fact reallocating a new buffer.

Before:

test string::tests::bench_exact_size_shrink_to_fit         ... bench:        45 ns/iter (+/- 2)

After:

test string::tests::bench_exact_size_shrink_to_fit         ... bench:        26 ns/iter (+/- 1)

This uses `Vec::shrink_to_fit()` internally so it's really benchmarking
that.
`Vec::shrink_to_fit()` may be called on vectors that are already the
correct length. Calling out to `reallocate()` in this case is a bad idea
because there is no guarantee that `reallocate()` won't allocate a new
buffer anyway, and based on performance seen in external benchmarks, it
seems likely that it is in fact reallocating a new buffer.

Before:

    test string::tests::bench_exact_size_shrink_to_fit         ... bench:        45 ns/iter (+/- 2)

After:

    test string::tests::bench_exact_size_shrink_to_fit         ... bench:        26 ns/iter (+/- 1)
@rust-highfive
Copy link
Contributor

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@Gankra
Copy link
Contributor

Gankra commented Jan 19, 2015

How does this impact code that actually needs to shrink?

@Gankra
Copy link
Contributor

Gankra commented Jan 19, 2015

(I imagine the overhead is negligable if not free, but am still curious)

@lilyball
Copy link
Contributor Author

@gankro I would imagine it's negligible too. It's a single comparison, of values that are already being used anyway so no cache faults or anything like that. I would welcome some actual profiling but I doubt I can get any meaningful measurements.

@nikomatsakis
Copy link
Contributor

@bors r+ c384ee1

bors added a commit that referenced this pull request Jan 26, 2015
Don't reallocate when capacity is already equal to length

`Vec::shrink_to_fit()` may be called on vectors that are already the
correct length. Calling out to `reallocate()` in this case is a bad idea
because there is no guarantee that `reallocate()` won't allocate a new
buffer anyway, and based on performance seen in external benchmarks, it
seems likely that it is in fact reallocating a new buffer.

Before:

    test string::tests::bench_exact_size_shrink_to_fit         ... bench:        45 ns/iter (+/- 2)

After:

    test string::tests::bench_exact_size_shrink_to_fit         ... bench:        26 ns/iter (+/- 1)
@bors
Copy link
Collaborator

bors commented Jan 26, 2015

⌛ Testing commit c384ee1 with merge 977c44a...

@bors
Copy link
Collaborator

bors commented Jan 26, 2015

@bors bors merged commit c384ee1 into rust-lang:master Jan 26, 2015
@lilyball lilyball deleted the optimize-shrink-to-fit branch March 15, 2015 00:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants