-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Optimize shallow_resolve_changed
#67079
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
Optimize shallow_resolve_changed
#67079
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 01025ef6e9babe54a3dad067d878c87deaf55a31 with merge d4119bbbe06d9b4edebef7f71ab6acafff5d0bfa... |
☀️ Try build successful - checks-azure |
Queued d4119bbbe06d9b4edebef7f71ab6acafff5d0bfa with parent 234c9f2, future comparison URL. |
Finished benchmarking try commit d4119bbbe06d9b4edebef7f71ab6acafff5d0bfa, comparison URL. |
Seems like it's not really a win, but I'm not opposed to landing it. |
Seems like a net loss, so why land it? |
That's weird... it was a clear win of about 3-4% on |
01025ef
to
0cb6b45
Compare
I rebased and double-checked the results. Here's what I get locally:
Let's try again. @bors try @rust-timer queue |
Awaiting bors try build completion |
…r=<try> Optimize `shallow_resolve_changed` r? @nikomatsakis
☀️ Try build successful - checks-azure |
Queued ec4d9e0 with parent 59947fc, future comparison URL. |
Finished benchmarking try commit ec4d9e0, comparison URL. |
@Mark-Simulacrum: no data is being shown in the results. (Likewise in #66405.) Any idea what's wrong? |
The new results are finished and they are basically a wash: some slight improvements, some slight regressions. This makes no sense to me.
I don't know what to do with this. |
It can be made even more specialized.
From a `Vec<Ty>` to a `Vec<InferTy>`, because that's a more restrictive type. This is a perf win because the ultra-hot function `shallow_resolve_changed` has less pattern-matching to do.
I did another local perf run, a full one this time. Results are the same as what I got before, and don't match the CI results:
Argh. |
0cb6b45
to
21f35bc
Compare
Let's try one more time. @bors try @rust-timer queue |
Awaiting bors try build completion |
…r=<try> Optimize `shallow_resolve_changed` r? @nikomatsakis
@nnethercote Maybe it's worth trying to benchmark locally with the CI build (i.e., using |
☀️ Try build successful - checks-azure |
Queued 9f4ea4a with parent 033662d, future comparison URL. |
Finished benchmarking try commit 9f4ea4a, comparison URL. |
Having trouble with the comparison URL :( Not sure what's going on with those things |
Maybe it needs to be rebased so that the comparison is based off a more recent commit? |
The CI run does two sets of benchmarking, one for the commits, and one for the parent (the baseline). rust-timer reports back when the first set is done, but the URL doesn't display results successfully until the parent is also done. It's in the queue right now, should be finished soon. I also suspect a bug in rustc-perf... I am also getting mismatches between local results and CI results in #66405. I am investigating now. |
The latest perf run has finished and the results are closer to what I'd expect (wins on |
I have a suspicion that there is a bug in rustc-perf or rust-timer causing the wrong revisions to be measured by CI. See rust-lang#66405 and rust-lang#67079 for more details. This commit deliberately causes a massive regression to the `token-stream-stress` benchmark. On my machine, the instruction count goes from 313M to 6084M, an 1843.4% regression. I want to see if a CI run replicates that.
[DO NOT LAND] Regress the `token-stream-stress` benchmark. I have a suspicion that there is a bug in rustc-perf or rust-timer causing the wrong revisions to be measured by CI. See #66405 and #67079 for more details. This commit deliberately causes a massive regression to the `token-stream-stress` benchmark. On my machine, the instruction count goes from 313M to 6084M, an 1843.4% regression. I want to see if a CI run replicates that. cc @Mark-Simulacrum r? @ghost
#67248 suggests that CI is working as expected. The most recent CI perf results are good, even though they're not as good as what I saw locally. And logically, the code is clearly better. I will land this, though I'm still uneasy about the variability of the CI perf results. r=nikomatsakis |
@bors r=nikomatsakis |
📌 Commit 21f35bc has been approved by |
@bors rollup=never |
@nnethercote are you building locally with jemalloc enabled? Also difference of glibc versions could make big difference here. |
…r=nikomatsakis Optimize `shallow_resolve_changed` r? @nikomatsakis
☀️ Test successful - checks-azure |
r? @nikomatsakis