Skip to content
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

Remove OneVector type alias #53824

Merged
merged 1 commit into from
Sep 26, 2018
Merged

Remove OneVector type alias #53824

merged 1 commit into from
Sep 26, 2018

Conversation

ljedrz
Copy link
Contributor

@ljedrz ljedrz commented Aug 30, 2018

Removes the OneVector type alias (equivalent to SmallVec<[T; 1]>); it is used in scenarios where the capacity of 1 is often exceeded, which might be nullifying the performance wins (due to spilling to the heap) expected when using SmallVec instead of Vec.

The numbers I used in this PR are very rough estimates - it would probably be a good idea to adjust some/all of them, which is what this proposal is all about.

It might be a good idea to additionally create some local type aliases for the SmallVecs in the Folder trait, as they are repeated in quite a few spots; I'd be happy to apply this sort of adjustments.

@rust-highfive
Copy link
Collaborator

r? @eddyb

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 30, 2018
@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Aug 31, 2018

☔ The latest upstream changes (presumably #53832) made this pull request unmergeable. Please resolve the merge conflicts.

@llogiq
Copy link
Contributor

llogiq commented Aug 31, 2018

FYI: I''ve started writing a smallvectune crate that can wrap SmallVec and log capacity information by internal array size over the course of the various constructors, resizings and deallocations. There are still some things to do, but once it's working, we could use this to help us gauge optimal internal array sizes for some workloads.

@ljedrz
Copy link
Contributor Author

ljedrz commented Sep 11, 2018

Rebased.

@eddyb
Copy link
Member

eddyb commented Sep 11, 2018

@nnethercote
Copy link
Contributor

This PR currently makes two changes:

  • remove the OneVector type alias (and ExpectOne);
  • expand almost all of the formerly OneVector small vecs from 1 inline entry to 4 (and one in transcribe.rs to 8).

The first change seems fine. I agree that OneVector is not a particularly good name. You also mention the possibility of adding new type aliases. SmallVec1, SmallVec4, etc., would be clearer, but I'm not sure if they are necessary.

I'm less satisfied by the second change. The description above says "it is used in scenarios where the capacity of 1 is often exceeded, which might be nullifying the performance wins" -- do you have any measurements showing this? My general approach is profile-driven: I assume the existing code is reasonable, and only change such things when I have measurements showing it helps. I'm not comfortable with a blanket approach of changing every OneVector to have 4 inline entries without measurements. Avoiding heap allocation is good in general, but SmallVec can cause extra memcpy calls and I have seen cases where the cost of the additional copying exceeding the savings from the avoided heap allocations. It could also increase memory usage.

To move forward I would suggest removing OneVector and changing all its uses to SmallVector<[T; 1]> is fine. Beyond that, I think it's only worth changing SmallVec lengths when measurements show it helps. @llogiq's smallvectune crate could be very useful for that.

Copy link
Contributor

@nnethercote nnethercote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Changes requested are above.)

@@ -70,7 +70,7 @@ pub fn transcribe(cx: &ExtCtxt,
interp: Option<FxHashMap<Ident, Rc<NamedMatch>>>,
src: Vec<quoted::TokenTree>)
-> TokenStream {
let mut stack: OneVector<Frame> = smallvec![Frame::new(src)];
let mut stack: SmallVec<[Frame; 8]> = smallvec![Frame::new(src)];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the one that is changed to 8, BTW.

@scottmcm scottmcm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 12, 2018
@ljedrz
Copy link
Contributor Author

ljedrz commented Sep 12, 2018

@nnethercote Thanks for the review! I wasn't aware these values were profiled and I now understand that changing them in an ad-hoc manner could be just as bad as spilling to the heap.

I agree that waiting for a more precise solution is the right choice. The adjusted PR should make this future change easier.

@nnethercote
Copy link
Contributor

I wasn't aware these values were profiled and I now understand that changing them in an ad-hoc manner could be just as bad as spilling to the heap.

Well, it's possible they are profiled, I don't know for sure. You could work it out with git blame if you really wanted. It's also possible that the exact size doesn't matter for a lot of them. But in the absence of measurements, I think it's best to leave things as they are. This is basically Chesterton's Fence in action:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

In this case measurements are the equivalent of the "Go away and think" part.

@llogiq
Copy link
Contributor

llogiq commented Sep 13, 2018

smallvectune has reached its first milestone: The data collector should work now, and uses an MPSC to collect the traces, so it's all thread-safe and shouldn't be too much of a performance burden (that said, I haven't benchmarked it...).

@bors
Copy link
Contributor

bors commented Sep 17, 2018

☔ The latest upstream changes (presumably #54277) made this pull request unmergeable. Please resolve the merge conflicts.

@TimNN
Copy link
Contributor

TimNN commented Sep 25, 2018

Ping from triage! @nnethercote / @ljedrz: Could you confirm the status of this PR? IIUC, it now only removes a type alias and uses a SmallVec implementation from an external crate.

@nnethercote
Copy link
Contributor

As per #53824 (comment), I suggest that @ljedrz changes this PR to just be about removing OneVector, and then does size tuning in a follow-up.

@ljedrz
Copy link
Contributor Author

ljedrz commented Sep 26, 2018

@nnethercote actually I already did that. I'll rebase it, this change should make future size tuning easier.

@ljedrz
Copy link
Contributor Author

ljedrz commented Sep 26, 2018

Rebased.

@michaelwoerister
Copy link
Member

Looking good!
@bors r+

@bors
Copy link
Contributor

bors commented Sep 26, 2018

📌 Commit 130a32f has been approved by michaelwoerister

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 26, 2018
@bors
Copy link
Contributor

bors commented Sep 26, 2018

⌛ Testing commit 130a32f with merge c3a1a0d...

bors added a commit that referenced this pull request Sep 26, 2018
Remove OneVector, increase related SmallVec capacities

Removes the `OneVector` type alias (equivalent to `SmallVec<[T; 1]>`); it is used in scenarios where the capacity of 1 is often exceeded, which might be nullifying the performance wins (due to spilling to the heap) expected when using `SmallVec` instead of `Vec`.

The numbers I used in this PR are very rough estimates - it would probably be a good idea to adjust some/all of them, which is what this proposal is all about.

It might be a good idea to additionally create some local type aliases for the `SmallVec`s in the `Folder` trait, as they are repeated in quite a few spots; I'd be happy to apply this sort of adjustments.
@bors
Copy link
Contributor

bors commented Sep 26, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing c3a1a0d to master...

@bors bors merged commit 130a32f into rust-lang:master Sep 26, 2018
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #53824!

Tested on commit c3a1a0d.
Direct link to PR: #53824

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Sep 26, 2018
Tested on commit rust-lang/rust@c3a1a0d.
Direct link to PR: <rust-lang/rust#53824>

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).
@ljedrz ljedrz deleted the begone_onevector branch September 26, 2018 12:41
@ljedrz ljedrz changed the title Remove OneVector, increase related SmallVec capacities Remove OneVector type alias Sep 26, 2018
matthiaskrgr added a commit to matthiaskrgr/rust-clippy that referenced this pull request Sep 26, 2018
fix breakage by rust-lang/rust#53824

use smallvec crate instead of rustcs type alias.
@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 2, 2018

This broke interpolate idents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants