Uh oh!
There was an error while loading. Please reload this page.
Prefer sort_unstable*() over sort*() - #52672
Conversation
rust-highfive
commented
Jul 24, 2018
(rust_highfive has picked a reviewer for you, use r? to override) |
| data.sort_by(|&(_,_,_,self1),&(_,_,_,self2)| | ||
| if self1 > self2 { Ordering::Less } else { Ordering::Greater } ); | ||
| data.sort_unstable_by(|&(_,_,_,self1),&(_,_,_,self2)| | ||
| if self1 > self2 { Ordering::Less } else { Ordering::Greater } ); |
There was a problem hiding this comment.
This one could be data.sort_unstable_by_key(|k| Reverse(&k.3)), which also handles the case self1 == self2 correctly
There was a problem hiding this comment.
The compiler seems to prefer data.sort_unstable_by_key(|&k| Reverse(k.3)). Looks like a readability win, I'll be happy to squash it in if the PR is accepted.
leonardo-m
commented
Jul 24, 2018
Are you sure that an unstable sorting keeps the code semantics correct in every one of those cases? |
ljedrz
commented
Jul 24, 2018
@leonardo-m I ran |
kennytm
commented
Jul 24, 2018
I'd like to ensure the CI to give a ✅ before perf. |
petrochenkov
commented
Jul 24, 2018
Travis is green. |
bors
commented
Jul 24, 2018
Prefer sort_unstable*() over sort*() Since `sort_unstable` is considered typically faster than the regular `sort` ([benchmarks](#40601 (comment))), it might be a good idea to check for potential wins in the compiler.
bors
commented
Jul 24, 2018
☀️ Test successful - status-travis |
kennytm
commented
Jul 24, 2018
@rust-timer build 90ec471 |
rust-timer
commented
Jul 24, 2018
Success: Queued 90ec471 with parent f498e4e, comparison URL. |
| optimizing.sort_by_key(|&x| { | ||
| optimizing.sort_unstable_by_key(|&x| { | ||
| // Place ZSTs first to avoid "interesting offsets", | ||
| // especially with only one or two non-ZST fields. |
There was a problem hiding this comment.
Struct layout not being stable sounds scary, even if technically allowed. I never want "my code got faster/slower because I added another ZST" to be something that happens.
| lints.sort_by(|&(x, _): &(&'static str, Vec<lint::LintId>), | ||
| &(y, _): &(&'static str, Vec<lint::LintId>)| { | ||
| lints.sort_unstable_by(|&(x, _): &(&'static str, Vec<lint::LintId>), | ||
| &(y, _): &(&'static str, Vec<lint::LintId>)| { |
There was a problem hiding this comment.
nit: looks like this could be _by_key too?
Perf is ready. Heh, some checks have even become slower. No big impact in total. |
ljedrz
commented
Jul 25, 2018
Yeah, it looks like there is no added value to changing to an unstable sort on this scale. I'll close this PR and file another one with the readability improvements. |
ghost
commented
Jul 25, 2018
Looks like some |
ljedrz
commented
Jul 25, 2018
Those wins are minor, but they seem consistent. The exclusion of other changes might even boost them, as some of them were regressions. I could limit the PR to NLL-only changes; @kennytm: shall I? If so, in this PR with a rebase or in another one? |
kennytm
commented
Jul 25, 2018
Let's reuse this PR. |
ljedrz
commented
Jul 25, 2018
@kennytm done. |
kennytm
commented
Jul 25, 2018
@bors try |
bors
commented
Jul 25, 2018
⌛ Trying commit 33d5362 with merge 15c727e088d78920db2c4590d723286550ce429b... |
bors
commented
Jul 25, 2018
☀️ Test successful - status-travis |
kennytm
commented
Jul 25, 2018
@rust-timer build 15c727e088d78920db2c4590d723286550ce429b |
rust-timer
commented
Jul 25, 2018
Success: Queued 15c727e088d78920db2c4590d723286550ce429b with parent fefe816, comparison URL. |
ljedrz
commented
Jul 26, 2018
Where have the NLL gains gone 😖? |
petrochenkov
commented
Jul 26, 2018
r? @kennytm |
pnkfelix
commented
Jul 27, 2018
None of these changes are for hot or even lukewarm code. Closing PR |
Since
sort_unstableis considered typically faster than the regularsort(benchmarks), it might be a good idea to check for potential wins in the compiler.