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

Fixing the performance regression of #76244 #76913

Merged
merged 1 commit into from
Sep 22, 2020

Conversation

vandenheuvel
Copy link
Contributor

Issue #74865 suggested that removing the def_id field from ParamEnv would improve performance. PR #76244 implemented this change.

Generally, results were as expected: an instruction count decrease of about a percent. The instruction count for the unicode crates increased by about 3%, which @nnethercote speculated to be caused by a quirk of inlining or codegen. As the results were generally positive, and for chalk integration, this was also a step in the right direction, the PR was r+'d regardless.

However, wall-time performance results show a much larger performance degradation: 25%, as mentioned by @Mark-Simulacrum.

This PR, for now, reverts #76244 and attempts to find out, which change caused the regression.

@rust-highfive
Copy link
Collaborator

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 Sep 19, 2020
@vandenheuvel
Copy link
Contributor Author

r? @jackh726

@rust-highfive rust-highfive assigned jackh726 and unassigned varkor Sep 19, 2020
@lcnr
Copy link
Contributor

lcnr commented Sep 19, 2020

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Sep 19, 2020

⌛ Trying commit 64f98169e0dda32efd981d568cebddad45d0b3cf with merge 62832cf234653ae26c54abc4801db9b0698a0f86...

@jackh726
Copy link
Member

Do try builds ignore tidy? If not, it will fail.

@lcnr
Copy link
Contributor

lcnr commented Sep 19, 2020

I think they ignore tidy

@bors
Copy link
Contributor

bors commented Sep 19, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: 62832cf234653ae26c54abc4801db9b0698a0f86 (62832cf234653ae26c54abc4801db9b0698a0f86)

@rust-timer
Copy link
Collaborator

Queued 62832cf234653ae26c54abc4801db9b0698a0f86 with parent 4e8a8b4, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (62832cf234653ae26c54abc4801db9b0698a0f86): 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

@jackh726
Copy link
Member

Ok cool, reverting the DefId removal wins us back the regressions.

@Mark-Simulacrum
Copy link
Member

Yeah, seems like maybe not all of it, but I think we should land this and separately explore why removing the DefId cost us so much performance on some benchmarks. (I guess maybe it would be fairly clear from the diff, but I'd need to view it locally I suspect).

@vandenheuvel vandenheuvel force-pushed the performance_debug branch 4 times, most recently from 29cdc76 to 44920d0 Compare September 19, 2020 20:11
@vandenheuvel
Copy link
Contributor Author

The latest commit reintroduces the refactor for chalk mode, as these changes are still desired. At this point, the net effect of this PR essentially is to introduce dead code. A FIXME is added to remove the field.

@Mark-Simulacrum
Copy link
Member

@bors try @rust-timer queue

Let's re-confirm perf.

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Sep 19, 2020

⌛ Trying commit 44920d01d523ae17e2da07ebe7d9a8c628cdadb8 with merge 7ccd8cf9305ba5c78cfd78c0fa454f18a20c4b16...

@bors
Copy link
Contributor

bors commented Sep 19, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: 7ccd8cf9305ba5c78cfd78c0fa454f18a20c4b16 (7ccd8cf9305ba5c78cfd78c0fa454f18a20c4b16)

@rust-timer
Copy link
Collaborator

Queued 7ccd8cf9305ba5c78cfd78c0fa454f18a20c4b16 with parent 59fb88d, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (7ccd8cf9305ba5c78cfd78c0fa454f18a20c4b16): 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

@jackh726
Copy link
Member

This is a seriously small diff. But LGTM. I don't know who wants to actually review/r+ this? @Mark-Simulacrum?

Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a comment

Choose a reason for hiding this comment

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

r=me with field made private, unless you want to try the MaybeUninit thing as well.

@@ -1745,6 +1745,9 @@ pub struct ParamEnv<'tcx> {
///
/// Note: This is packed, use the reveal() method to access it.
packed: CopyTaggedPtr<&'tcx List<Predicate<'tcx>>, traits::Reveal, true>,

/// FIXME: This field is not used, but removing it causes a performance degradation. See #76913.
pub unused_field: Option<DefId>,
Copy link
Member

Choose a reason for hiding this comment

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

I would like this to be made private.

Maybe we should also replace Option<DefId> here with something like MaybeUninit<u64>, which would never be initialized, and see if that's still enough to avoid the regression?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Private: good point!

About the different type: I'm not sure what a nice solution would be. MaybeUninit is not Eq, for example. I now wrapped an array of u8's to stress that the side (probably) should be 8 bytes. What do you think?

@Mark-Simulacrum
Copy link
Member

Could you squash the commits down as well? I imagine the revert re-apply dance are no longer necessary, given the small diff here.

Let's kick off a try build to make sure the array doesn't perform worse. @bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Sep 20, 2020

⌛ Trying commit 106b74ba1a5abe1b617b33be0b440ea065080666 with merge 3b689b941bcd1844d1fae487ae64b061bb4492c3...

@bors
Copy link
Contributor

bors commented Sep 20, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: 3b689b941bcd1844d1fae487ae64b061bb4492c3 (3b689b941bcd1844d1fae487ae64b061bb4492c3)

@rust-timer
Copy link
Collaborator

Queued 3b689b941bcd1844d1fae487ae64b061bb4492c3 with parent 1fd5b9d, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (3b689b941bcd1844d1fae487ae64b061bb4492c3): 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

@jackh726
Copy link
Member

Latest perf looks worse.

@Mark-Simulacrum
Copy link
Member

Okay, let's go back to the DefId and we can try to follow-up separately on optimizing further.

r=me with commits squashed so we don't have the back and forth in git history

@vandenheuvel
Copy link
Contributor Author

@Mark-Simulacrum I think that this should do it.

@lcnr
Copy link
Contributor

lcnr commented Sep 21, 2020

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Sep 21, 2020

📌 Commit ab83d37 has been approved by lcnr

@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 Sep 21, 2020
@bors
Copy link
Contributor

bors commented Sep 22, 2020

⌛ Testing commit ab83d37 with merge 4519845...

@bors
Copy link
Contributor

bors commented Sep 22, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: lcnr
Pushing 4519845 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 22, 2020
@bors bors merged commit 4519845 into rust-lang:master Sep 22, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 22, 2020
@vandenheuvel vandenheuvel deleted the performance_debug branch September 22, 2020 13:46
@vandenheuvel
Copy link
Contributor Author

This issue finds continuation in #77058.

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.

9 participants