Implement requestPaint in the actual scheduler #31784
Merged
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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: c32780e...6bd1b00 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
sebmarkbage
force-pushed
the
requestpaint
branch
from
1060155 to
2d264e3
Compare
acdlite
approved these changes
Dec 14, 2024
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)
This was referenced Dec 14, 2024
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)
sebmarkbage
added a commit
that referenced
this pull request
Dec 17, 2024
…mpletes (#31787) As an alternative to #31784. We should really just always yield each virtual task to a native task. So that it's 1:1 with native tasks. This affects when microtasks within each task happens. This brings us closer to native `postTask` semantics which makes it more seamless to just use that when available. This still doesn't yield when a task expires to protect against starvation.
github-actions bot
pushed a commit
that referenced
this pull request
Dec 17, 2024
…mpletes (#31787) As an alternative to #31784. We should really just always yield each virtual task to a native task. So that it's 1:1 with native tasks. This affects when microtasks within each task happens. This brings us closer to native `postTask` semantics which makes it more seamless to just use that when available. This still doesn't yield when a task expires to protect against starvation. DiffTrain build for [f5077bc](f5077bc)
sebmarkbage
added a commit
that referenced
this pull request
Dec 17, 2024
…led flow (#31785) This treats workInProgressRoot work and rootWithPendingPassiveEffects the same way. Basically as long as there's some work on the root, yield the current task. Including passive effects. This means that passive effects are now a continuation instead of a separate callback. This can mean they're earlier or later than before. Later for Idle in case there's other non-React work. Earlier for same Default if there's other Default priority work. This makes sense since increasing priority of the passive effects beyond Idle doesn't really make sense for an Idle render. However, for any given render at same priority it's more important to complete this work than start something new. Since we special case continuations to always yield to the browser, this has the same effect as #31784 without implementing `requestPaint`. At least assuming nothing else calls `requestPaint`. <img width="587" alt="Screenshot 2024-12-14 at 5 37 37 PM" src="https://github.com/user-attachments/assets/8641b172-8842-4191-8bf0-50cbe263a30c" />
github-actions bot
pushed a commit
that referenced
this pull request
Dec 17, 2024
…led flow (#31785) This treats workInProgressRoot work and rootWithPendingPassiveEffects the same way. Basically as long as there's some work on the root, yield the current task. Including passive effects. This means that passive effects are now a continuation instead of a separate callback. This can mean they're earlier or later than before. Later for Idle in case there's other non-React work. Earlier for same Default if there's other Default priority work. This makes sense since increasing priority of the passive effects beyond Idle doesn't really make sense for an Idle render. However, for any given render at same priority it's more important to complete this work than start something new. Since we special case continuations to always yield to the browser, this has the same effect as #31784 without implementing `requestPaint`. At least assuming nothing else calls `requestPaint`. <img width="587" alt="Screenshot 2024-12-14 at 5 37 37 PM" src="https://github.com/user-attachments/assets/8641b172-8842-4191-8bf0-50cbe263a30c" /> DiffTrain build for [facec3e](facec3e)
github-actions bot
pushed a commit
that referenced
this pull request
Dec 17, 2024
…led flow (#31785) This treats workInProgressRoot work and rootWithPendingPassiveEffects the same way. Basically as long as there's some work on the root, yield the current task. Including passive effects. This means that passive effects are now a continuation instead of a separate callback. This can mean they're earlier or later than before. Later for Idle in case there's other non-React work. Earlier for same Default if there's other Default priority work. This makes sense since increasing priority of the passive effects beyond Idle doesn't really make sense for an Idle render. However, for any given render at same priority it's more important to complete this work than start something new. Since we special case continuations to always yield to the browser, this has the same effect as #31784 without implementing `requestPaint`. At least assuming nothing else calls `requestPaint`. <img width="587" alt="Screenshot 2024-12-14 at 5 37 37 PM" src="https://github.com/user-attachments/assets/8641b172-8842-4191-8bf0-50cbe263a30c" /> DiffTrain build for [facec3e](facec3e)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 18, 2024
…led flow (facebook#31785) This treats workInProgressRoot work and rootWithPendingPassiveEffects the same way. Basically as long as there's some work on the root, yield the current task. Including passive effects. This means that passive effects are now a continuation instead of a separate callback. This can mean they're earlier or later than before. Later for Idle in case there's other non-React work. Earlier for same Default if there's other Default priority work. This makes sense since increasing priority of the passive effects beyond Idle doesn't really make sense for an Idle render. However, for any given render at same priority it's more important to complete this work than start something new. Since we special case continuations to always yield to the browser, this has the same effect as facebook#31784 without implementing `requestPaint`. At least assuming nothing else calls `requestPaint`. <img width="587" alt="Screenshot 2024-12-14 at 5 37 37 PM" src="https://github.com/user-attachments/assets/8641b172-8842-4191-8bf0-50cbe263a30c" /> DiffTrain build for [facec3e](facebook@facec3e)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 18, 2024
…led flow (facebook#31785) This treats workInProgressRoot work and rootWithPendingPassiveEffects the same way. Basically as long as there's some work on the root, yield the current task. Including passive effects. This means that passive effects are now a continuation instead of a separate callback. This can mean they're earlier or later than before. Later for Idle in case there's other non-React work. Earlier for same Default if there's other Default priority work. This makes sense since increasing priority of the passive effects beyond Idle doesn't really make sense for an Idle render. However, for any given render at same priority it's more important to complete this work than start something new. Since we special case continuations to always yield to the browser, this has the same effect as facebook#31784 without implementing `requestPaint`. At least assuming nothing else calls `requestPaint`. <img width="587" alt="Screenshot 2024-12-14 at 5 37 37 PM" src="https://github.com/user-attachments/assets/8641b172-8842-4191-8bf0-50cbe263a30c" /> DiffTrain build for [facec3e](facebook@facec3e)
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.
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 theisInputPendingexperiment. 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 theisInputPendingexperiment 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 withisInputPendingat 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
requestPaintis called.Before:
After:
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. 😬