Delete requestPaint from Scheduler #31782
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's a noop so it's misleading.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
added a commit
that referenced
this pull request
Dec 14, 2024
When implementing passive effects we did a pretty massive oversight. While the passive effect is scheduled into its own scheduler task, the scheduler doesn't always yield to the browser if it has time left. That means that if you have a fast commit phase, it might try to squeeze in the passive effects in the same frame but those then might end being very heavy. We had `requestPaint()` for this but that was only implemented for the `isInputPending` experiment. It wasn't thought we needed it for the regular scheduler because it yields "every frame" anyway - but it doesn't yield every task. While the `isInputPending` experiment showed that it wasn't actually any significant impact, and it was better to keep shorter yield time anyway. Which is why we deleted the code. Whatever small win it did see in some cases might have been actually due to this issue rather than anything to do with `isInputPending` at all. As you can see in #31782 we do have this implemented in the mock scheduler and a lot of behavior that we assert assumes that this works. So this just implements yielding after `requestPaint` is called. Before: <img width="1023" alt="Screenshot 2024-12-14 at 3 40 24 PM" src="https://github.com/user-attachments/assets/d60f4bb2-c8f8-4f91-a402-9ac25b278450" /> After: <img width="1108" alt="Screenshot 2024-12-14 at 3 41 25 PM" src="https://github.com/user-attachments/assets/170cdb90-a049-436f-9501-be3fb9bc04ca" /> Notice how in after the native task is split into two. It might not always actually paint and the native scheduler might make the same mistake and think it has enough time left but it's at least less likely to. We do have another way to do this. When we yield a continuation we also yield to the native browser. This is to enable the Suspense Optimization (currently disabled) to work. We could do the same for passive effects and, in fact, I have a branch that does but because that requires a lot more tests to be fixed it's a lot more invasive of a change. The nice thing about this approach is that this is not even running in tests at all and the tests we do have assert that this is the behavior already. 😬
github-actions bot
pushed a commit
that referenced
this pull request
Dec 14, 2024
When implementing passive effects we did a pretty massive oversight. While the passive effect is scheduled into its own scheduler task, the scheduler doesn't always yield to the browser if it has time left. That means that if you have a fast commit phase, it might try to squeeze in the passive effects in the same frame but those then might end being very heavy. We had `requestPaint()` for this but that was only implemented for the `isInputPending` experiment. It wasn't thought we needed it for the regular scheduler because it yields "every frame" anyway - but it doesn't yield every task. While the `isInputPending` experiment showed that it wasn't actually any significant impact, and it was better to keep shorter yield time anyway. Which is why we deleted the code. Whatever small win it did see in some cases might have been actually due to this issue rather than anything to do with `isInputPending` at all. As you can see in #31782 we do have this implemented in the mock scheduler and a lot of behavior that we assert assumes that this works. So this just implements yielding after `requestPaint` is called. Before: <img width="1023" alt="Screenshot 2024-12-14 at 3 40 24 PM" src="https://github.com/user-attachments/assets/d60f4bb2-c8f8-4f91-a402-9ac25b278450" /> After: <img width="1108" alt="Screenshot 2024-12-14 at 3 41 25 PM" src="https://github.com/user-attachments/assets/170cdb90-a049-436f-9501-be3fb9bc04ca" /> Notice how in after the native task is split into two. It might not always actually paint and the native scheduler might make the same mistake and think it has enough time left but it's at least less likely to. We do have another way to do this. When we yield a continuation we also yield to the native browser. This is to enable the Suspense Optimization (currently disabled) to work. We could do the same for passive effects and, in fact, I have a branch that does but because that requires a lot more tests to be fixed it's a lot more invasive of a change. The nice thing about this approach is that this is not even running in tests at all and the tests we do have assert that this is the behavior already. 😬 DiffTrain build for [c80b336](c80b336)
github-actions bot
pushed a commit
that referenced
this pull request
Dec 14, 2024
When implementing passive effects we did a pretty massive oversight. While the passive effect is scheduled into its own scheduler task, the scheduler doesn't always yield to the browser if it has time left. That means that if you have a fast commit phase, it might try to squeeze in the passive effects in the same frame but those then might end being very heavy. We had `requestPaint()` for this but that was only implemented for the `isInputPending` experiment. It wasn't thought we needed it for the regular scheduler because it yields "every frame" anyway - but it doesn't yield every task. While the `isInputPending` experiment showed that it wasn't actually any significant impact, and it was better to keep shorter yield time anyway. Which is why we deleted the code. Whatever small win it did see in some cases might have been actually due to this issue rather than anything to do with `isInputPending` at all. As you can see in #31782 we do have this implemented in the mock scheduler and a lot of behavior that we assert assumes that this works. So this just implements yielding after `requestPaint` is called. Before: <img width="1023" alt="Screenshot 2024-12-14 at 3 40 24 PM" src="https://github.com/user-attachments/assets/d60f4bb2-c8f8-4f91-a402-9ac25b278450" /> After: <img width="1108" alt="Screenshot 2024-12-14 at 3 41 25 PM" src="https://github.com/user-attachments/assets/170cdb90-a049-436f-9501-be3fb9bc04ca" /> Notice how in after the native task is split into two. It might not always actually paint and the native scheduler might make the same mistake and think it has enough time left but it's at least less likely to. We do have another way to do this. When we yield a continuation we also yield to the native browser. This is to enable the Suspense Optimization (currently disabled) to work. We could do the same for passive effects and, in fact, I have a branch that does but because that requires a lot more tests to be fixed it's a lot more invasive of a change. The nice thing about this approach is that this is not even running in tests at all and the tests we do have assert that this is the behavior already. 😬 DiffTrain build for [c80b336](c80b336)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 15, 2024
When implementing passive effects we did a pretty massive oversight. While the passive effect is scheduled into its own scheduler task, the scheduler doesn't always yield to the browser if it has time left. That means that if you have a fast commit phase, it might try to squeeze in the passive effects in the same frame but those then might end being very heavy. We had `requestPaint()` for this but that was only implemented for the `isInputPending` experiment. It wasn't thought we needed it for the regular scheduler because it yields "every frame" anyway - but it doesn't yield every task. While the `isInputPending` experiment showed that it wasn't actually any significant impact, and it was better to keep shorter yield time anyway. Which is why we deleted the code. Whatever small win it did see in some cases might have been actually due to this issue rather than anything to do with `isInputPending` at all. As you can see in facebook#31782 we do have this implemented in the mock scheduler and a lot of behavior that we assert assumes that this works. So this just implements yielding after `requestPaint` is called. Before: <img width="1023" alt="Screenshot 2024-12-14 at 3 40 24 PM" src="https://github.com/user-attachments/assets/d60f4bb2-c8f8-4f91-a402-9ac25b278450" /> After: <img width="1108" alt="Screenshot 2024-12-14 at 3 41 25 PM" src="https://github.com/user-attachments/assets/170cdb90-a049-436f-9501-be3fb9bc04ca" /> Notice how in after the native task is split into two. It might not always actually paint and the native scheduler might make the same mistake and think it has enough time left but it's at least less likely to. We do have another way to do this. When we yield a continuation we also yield to the native browser. This is to enable the Suspense Optimization (currently disabled) to work. We could do the same for passive effects and, in fact, I have a branch that does but because that requires a lot more tests to be fixed it's a lot more invasive of a change. The nice thing about this approach is that this is not even running in tests at all and the tests we do have assert that this is the behavior already. 😬 DiffTrain build for [c80b336](facebook@c80b336)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 15, 2024
When implementing passive effects we did a pretty massive oversight. While the passive effect is scheduled into its own scheduler task, the scheduler doesn't always yield to the browser if it has time left. That means that if you have a fast commit phase, it might try to squeeze in the passive effects in the same frame but those then might end being very heavy. We had `requestPaint()` for this but that was only implemented for the `isInputPending` experiment. It wasn't thought we needed it for the regular scheduler because it yields "every frame" anyway - but it doesn't yield every task. While the `isInputPending` experiment showed that it wasn't actually any significant impact, and it was better to keep shorter yield time anyway. Which is why we deleted the code. Whatever small win it did see in some cases might have been actually due to this issue rather than anything to do with `isInputPending` at all. As you can see in facebook#31782 we do have this implemented in the mock scheduler and a lot of behavior that we assert assumes that this works. So this just implements yielding after `requestPaint` is called. Before: <img width="1023" alt="Screenshot 2024-12-14 at 3 40 24 PM" src="https://github.com/user-attachments/assets/d60f4bb2-c8f8-4f91-a402-9ac25b278450" /> After: <img width="1108" alt="Screenshot 2024-12-14 at 3 41 25 PM" src="https://github.com/user-attachments/assets/170cdb90-a049-436f-9501-be3fb9bc04ca" /> Notice how in after the native task is split into two. It might not always actually paint and the native scheduler might make the same mistake and think it has enough time left but it's at least less likely to. We do have another way to do this. When we yield a continuation we also yield to the native browser. This is to enable the Suspense Optimization (currently disabled) to work. We could do the same for passive effects and, in fact, I have a branch that does but because that requires a lot more tests to be fixed it's a lot more invasive of a change. The nice thing about this approach is that this is not even running in tests at all and the tests we do have assert that this is the behavior already. 😬 DiffTrain build for [c80b336](facebook@c80b336)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's a noop so it's misleading. It's only implemented in the SchedulerMock. Which means that a bunch of our tests are actually testing behavior that doesn't work in the real runtime nor in tests when not using the mock. See failing tests.