Implement iterator specialization traits on more adapters#85528
Implement iterator specialization traits on more adapters#85528bors merged 4 commits intorust-lang:masterfrom
Conversation
|
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit 838b07beaca15f5614619bcee070ef5263a805ed with merge e056521d347c0ec9e2f6a0a140406f4b0a06c011... |
|
☀️ Try build successful - checks-actions |
|
Queued e056521d347c0ec9e2f6a0a140406f4b0a06c011 with parent 99e3aef, future comparison URL. |
|
Finished benchmarking try commit (e056521d347c0ec9e2f6a0a140406f4b0a06c011): 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 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 |
|
Looks like noise. Or if it isn't then it's tiny impact at least. I guess the I'll write some benchmarks to see if these actually improve some assembly. |
3b3e1bb to
5e1a4a3
Compare
|
I have added a benchmark |
There was a problem hiding this comment.
In light of #85969 I must note that this alters (undocumented) side-effects for backwards iteration, albeit in less surprising ways.
This block is written to preserve side-effects of the skipped portion of the iterator during forward iteration. During backward iteration it will lead to the whole skipped portion being drained on the last (backwards) step instead of only the first item beyond the skipped portion, i.e. it behaves as if the last item were obtained by a next() instead of next_back().
There was a problem hiding this comment.
Hm, so, my interpretation of what you're saying: we're picking idx == 0, which might not actually be the first index the user iterates over (and won't be in backwards iteration).
But I think my interpretation is probably wrong -- I've tried several times and I cannot manage to find a case where your patch causes different behavior in map(|i| dbg!(i)).skip(n) behavior in forward or backward iteration. Do you have an example where it makes causes an observable difference?
There was a problem hiding this comment.
next_back doesn't touch the inner's skipped prefix. But anything that goes backwards via __iterator_get_unchecked (e.g. Zip) would once it hits index 0.
There was a problem hiding this comment.
@the8472 Okay, this is a slight behavioral change to behavior we never made a promise about. I think it's a change we're allowed to make, but to be safe, that decision should be left to t-libs-api FCP.
Do you mind writing up the details about before/after differences so that that can be done?
|
Going to pass this one off because I'm not familiar enough with this part of r? @m-ou-se |
|
☔ The latest upstream changes (presumably #85874) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
|
⌛ Trying commit 3af552a with merge 1f4585dbcb1b7f4971a8c2a76d1b74dff98a774a... |
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (1f4585dbcb1b7f4971a8c2a76d1b74dff98a774a): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 652.994s -> 652s (-0.15%) |
|
idk, despite my enthusiasm for the exercising of the runtime perf test suite, with what feels like minimal/unclear benefit, it's hard to argue that the addition of a bunch of hard-to-audit |
|
r? libs-api Needs FCP due to inducing user-facing behavior changes in some iterator adapters in order to make the given microbenchmark go zoom. Behavior change is subtle, however, and doesn't seem to be earthshattering, see this comment. |
|
This causes a minor behavior change, see #85528 (comment). However I don't expect this to be an issue in practice since this behavior was never guaranteeed. @rfcbot fcp merge |
|
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
This is waiting on 1 more checkbox to enter FCP, among them @the8472's, whose PR this is. I almost but not quite feel at liberty to check your box for you. Want to do the honors? 😉 |
|
Sure, I can do that if that's ok? Approving one's own stuff always seems questionable. But I guess we'd have to tell the bot to remove one of the boxes, which we don't. 🤷 |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
@the8472 "N–2 of the team thinks that this is a good idea (and no objections)" is the bar. In my experience it's always been by design that the PR author would be included in that count if they're a member of the relevant team. Actually, most often the PR author is the one who proposes the FCP in the first place in that situation, so then they automatically get counted. |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
FCP complete, this should be ready to merge. ping @Amanieu or reassign to a libs reviewer now that the libs-api question is settled. |
|
@bors r+ |
|
💥 Test timed out |
|
Apple runner hanging. @bors retry |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (fa40433): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 662.48s -> 663.269s (0.12%) |

This adds
TrustedLentoSkipandStepByTrustedRandomAccesstoSkipInPlaceIterableandSourceItertoCopiedandClonedThe first two might improve performance in the compiler itself since
skipis used in several places. Constellations that would exercise the last point are probably rare since it would require an owning iterator that has references as Items somewhere in its iterator pipeline.Improvements for
Skip: