-
Notifications
You must be signed in to change notification settings - Fork 146
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
Faster insert for the index == len
case
#282
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
By skipping the call to `copy` with a zero length. This makes it closer to `push`. This speeds up rustc (which uses `SmallVec` extensively) by 2% on one benchmark. Also clarify the panic condition.
This is the relevant use point within Rust, if you are curious. |
mbrubeck
approved these changes
Jun 24, 2022
Thanks! Released as v1.8.1: https://crates.io/crates/smallvec/1.8.1 |
nnethercote
added a commit
to nnethercote/rust
that referenced
this pull request
Jun 26, 2022
This pulls in servo/rust-smallvec#282, which gives some small wins for rustc.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 29, 2022
Update `smallvec` to 1.8.1. This pulls in servo/rust-smallvec#282, which gives some small wins for rustc. r? `@lqd`
nnethercote
added a commit
to nnethercote/rust
that referenced
this pull request
Jul 1, 2022
By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (servo/rust-smallvec#282) and it was a big perf win in one case. Although I don't have a specific use case in mind, it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case, the number of conditions checked is unchanged. - In the `index == len` case, the number of conditions checked increases by one, but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 3, 2022
Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (servo/rust-smallvec#282) and it was a big perf win in one case. Although I don't have a specific use case in mind, it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case, the number of conditions checked is unchanged. - In the `index == len` case, the number of conditions checked increases by one, but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`
bjorn3
pushed a commit
to rust-lang/rustc_codegen_cranelift
that referenced
this pull request
Jul 3, 2022
This pulls in servo/rust-smallvec#282, which gives some small wins for rustc.
workingjubilee
pushed a commit
to tcdi/postgrestd
that referenced
this pull request
Sep 15, 2022
By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (servo/rust-smallvec#282) and it was a big perf win in one case. Although I don't have a specific use case in mind, it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case, the number of conditions checked is unchanged. - In the `index == len` case, the number of conditions checked increases by one, but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change.
workingjubilee
pushed a commit
to tcdi/postgrestd
that referenced
this pull request
Sep 15, 2022
Optimize `Vec::insert` for the case where `index == len`. By skipping the call to `copy` with a zero length. This makes it closer to `push`. I did this recently for `SmallVec` (servo/rust-smallvec#282) and it was a big perf win in one case. Although I don't have a specific use case in mind, it seems worth doing it for `Vec` as well. Things to note: - In the `index < len` case, the number of conditions checked is unchanged. - In the `index == len` case, the number of conditions checked increases by one, but the more expensive zero-length copy is avoided. - In the `index > len` case the code now reserves space for the extra element before panicking. This seems like an unimportant change. r? `@cuviper`
eddyb
pushed a commit
to LykenSol/rustc_apfloat-git-history-extraction
that referenced
this pull request
Nov 14, 2022
This pulls in servo/rust-smallvec#282, which gives some small wins for rustc. [git filter-repo] original commit: rust-lang/rust@7c40661
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This case popped up within rustc, where
insert
was repeatedly used for apush
-like operation. (But in a context wherepush
wasn't always appropriate.) It speeds up rustc on one benchmark by 2% -- not huge, but also not bad for such a small change.Here is some before and after results for the new benchmark along with the existing
push
benchmarks.Old:
New
The first two are testing identical code, and show that the time variation is non-trivial. The latter two show the effect of this PR's code changes, which are well beyond the timing variation.