-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
[WIP] Make into
schedule drop for the destination again
#65385
[WIP] Make into
schedule drop for the destination again
#65385
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit ac5531a84c6549f74a7d1ba772cf2ffafca4a03f with merge 657db25f5495ead2ced9bac02891196b47dac8a3... |
@bors retry try |
⌛ Trying commit ac5531a84c6549f74a7d1ba772cf2ffafca4a03f with merge 9a46f242f60618bf42c2d0ae1d088307b9464ba1... |
☀️ Try build successful - checks-azure |
Queued 9a46f242f60618bf42c2d0ae1d088307b9464ba1 with parent c27f756, future comparison URL. |
@@ -54,7 +54,6 @@ impl<A, B> Iterator for Chain<A, B> where | |||
{ | |||
type Item = A::Item; | |||
|
|||
#[inline] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With lto (thin or fat), these attributes shouldn't really make much of a difference. Is the performance regression still there when these are present ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These attributes were the cause of the perf regression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is that possible? The PR that introduced the regression did not add these attributes, so they must have already been there, right ? Without that PR, these attributes were not introducing that regression, so something else in that PR caused it.
Finished benchmarking try commit 9a46f242f60618bf42c2d0ae1d088307b9464ba1, comparison URL. |
Still regresses badly, especially |
You probably mean to ask @matthewjasper |
Ping from triage - Thanks! |
This reverts commit a0342c8
ac5531a
to
98c3371
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
98c3371
to
7d7dc00
Compare
Trying one more time before I close this and work on a different approach |
Awaiting bors try build completion |
[WIP] Make `into` schedule drop for the destination again #61430 triggered some degenerate behavior in llvm where it would inline functions far too aggressively. This is marked as WIP because it doesn't really solve the problem in general. I've opened this PR more so that there's a place to discuss fixes. <details> <summary>Minimized example of the problem</summary> Uncommenting the `#[inline]` will cause this to take a long time to compile on nightly, since llvm will inline all of the next calls into one enormous function that it spends a very long time handling. ```rust pub trait Iterator { type Item; fn next(&mut self) -> Self::Item; } pub struct Empty; impl Iterator for Empty { type Item = (); fn next(&mut self) {} } pub struct Chain<A, B=Empty> { a: A, b: B, state: ChainState, } #[allow(dead_code)] enum ChainState { Both, Front, Back, } impl<A, B> Iterator for Chain<A, B> where A: Iterator, B: Iterator<Item = A::Item> { type Item = A::Item; //#[inline] //^ uncomment me for degenerate llvm behvaiour with `-O` fn next(&mut self) -> A::Item { let ret; match self.state { ChainState::Both => { let _x = self.a.next(); self.state = ChainState::Back; ret = self.b.next() }, ChainState::Front => ret = self.a.next(), ChainState::Back => ret = self.b.next(), }; ret } } type Chain2<T> = Chain<Chain<T>>; type Chain4<T> = Chain2<Chain2<T>>; type Chain8<T> = Chain4<Chain4<T>>; type Chain16<T> = Chain8<Chain8<T>>; pub fn call_next(x: &mut Chain16<Empty>) { x.next() } ``` </details> Closes #47949
☀️ Try build successful - checks-azure |
Queued 8712d90 with parent f39205b, future comparison URL. |
Finished benchmarking try commit 8712d90, comparison URL. |
#61430 triggered some degenerate behavior in llvm where it would inline functions far too aggressively.
This is marked as WIP because it doesn't really solve the problem in general. I've opened this PR more so that there's a place to discuss fixes.
Minimized example of the problem
Uncommenting the
#[inline]
will cause this to take a long time to compile on nightly, since llvm will inline all of the next calls into one enormous function that it spends a very long time handling.Closes #47949