Skip to content

Conversation

bugadani
Copy link
Contributor

@bugadani bugadani commented Oct 30, 2020

In several cases, a Vec or SmallVec is passed to Arena::alloc_from_iter directly. This PR makes sure those cases don't copy their data unnecessarily, by specializing the alloc_from_iter implementation.

@rust-highfive
Copy link
Contributor

r? @varkor

(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 Oct 30, 2020
@bugadani
Copy link
Contributor Author

cc @est31

@varkor
Copy link
Member

varkor commented Nov 16, 2020

Apologies for taking so long; this slipped under my radar. I'm not familiar with this code, so I'm assigning to @Mark-Simulacrum based on git blame.

r? @Mark-Simulacrum

@bugadani bugadani force-pushed the arena-spec branch 4 times, most recently from 599683e to 43b83b3 Compare November 20, 2020 08:55
@bugadani
Copy link
Contributor Author

@Mark-Simulacrum I've done what I could. I've addressed your comments and reverted some changes based on those comments. For example, changes to write_from_iter are no longer part of this PR, as they aren't necessary any more.

@Mark-Simulacrum
Copy link
Member

@bors try @rust-timer queue

This should just be a win (or roughly neutral), but let's check. r=me otherwise.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Collaborator

bors commented Nov 20, 2020

⌛ Trying commit 43b83b334130ef066d8518ca2a125779399ccd73 with merge aa21b48c4d75183274998a446bae14e98053637a...

@bors
Copy link
Collaborator

bors commented Nov 20, 2020

☀️ Try build successful - checks-actions
Build commit: aa21b48c4d75183274998a446bae14e98053637a (aa21b48c4d75183274998a446bae14e98053637a)

@rust-timer
Copy link
Collaborator

Queued aa21b48c4d75183274998a446bae14e98053637a with parent c9c57fa, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (aa21b48c4d75183274998a446bae14e98053637a): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot modify labels: +S-waiting-on-review -S-waiting-on-perf

@bugadani
Copy link
Contributor Author

Interesting. I wonder if I see the results correctly - an increase in instruction counts, but in the same time, looking at the detailed results, a decrease in times? For example, this report belongs to a 0.5% instruction count regression, but shows a -0.3% total time diff: https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=match-stress-enum-check&run_name=incr-unchanged

Hmm.

@Mark-Simulacrum
Copy link
Member

I would say that this is perhaps a slight regression in instruction counts, but overall a win on cycles -- https://perf.rust-lang.org/compare.html?start=c9c57fadc47c8ad986808fc0a47479f6d2043453&end=aa21b48c4d75183274998a446bae14e98053637a&stat=cycles%3Au on non-incremental benchmarks. I am inclined to land it based on these performance results; it does not seem like an obvious win yet, but it does seem like something we should be doing to try and avoid potential problems for the cases optimized here.

@Mark-Simulacrum
Copy link
Member

Ok, r=me with commits squashed

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Nov 20, 2020

📌 Commit e93a463 has been approved by Mark-Simulacrum

@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-review Status: Awaiting review from the assignee but also interested parties. labels Nov 20, 2020
@est31
Copy link
Member

est31 commented Nov 20, 2020

Are the cycle numbers always this noisy? There is a 5% on incr-unchanged on the encoding-check benchmark. Apparently most of the slowdown comes from early_lint_checks being 50% slower. https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=encoding-check&run_name=incr-unchanged

Should this worry us?

@Mark-Simulacrum
Copy link
Member

Note that the 50% there is a wall clock measurement of 6ms, which is almost certainly noise. Cycle measurements frequently have noise in the 5% range on clean benchmarks; for incremental unchanged benchmarks they can be even noisier since there's less overall cycles on those.

I am not particularly worried.

@est31
Copy link
Member

est31 commented Nov 20, 2020

@Mark-Simulacrum thanks for the info!

@bors
Copy link
Collaborator

bors commented Nov 20, 2020

⌛ Testing commit e93a463 with merge 432d116...

@bors
Copy link
Collaborator

bors commented Nov 21, 2020

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 432d116 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 21, 2020
@bors bors merged commit 432d116 into rust-lang:master Nov 21, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 21, 2020
@rust-highfive
Copy link
Contributor

📣 Toolstate changed by #78569!

Tested on commit 432d116.
Direct link to PR: #78569

💔 rls on linux: test-pass → test-fail (cc @Xanewok).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Nov 21, 2020
Tested on commit rust-lang/rust@432d116.
Direct link to PR: <rust-lang/rust#78569>

💔 rls on linux: test-pass → test-fail (cc @Xanewok).
@bugadani bugadani deleted the arena-spec branch November 21, 2020 07:07
mem::forget(self);
slice::from_raw_parts_mut(start_ptr, len)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks like there are quite a bit of code duplication here, shouldn't it be refactored?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, it's not intentionally duplicated, but I couldn't find a way to make it significantly nicer. Unfortunately, we can't use alloc_from_slice because it requires the items to be Copy.

pickfire added a commit to pickfire/rust that referenced this pull request Dec 5, 2020
nnethercote added a commit to nnethercote/rust that referenced this pull request Oct 3, 2023
It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.
nnethercote added a commit to nnethercote/rust that referenced this pull request Oct 3, 2023
It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.

Also, add a comment explaining why the two `alloc_from_iter` functions
are so different.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2023
…llot

Remove the `TypedArena::alloc_from_iter` specialization.

It was added in rust-lang#78569. It's complicated and doesn't actually help
performance.

r? `@cjgillot`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. 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