[Fiber] Mark cascading updates #31866
Open
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
sebmarkbage
commented
Dec 20, 2024
| @@ -229,13 +229,17 @@ function flushSyncWorkAcrossRoots_impl( | |||
| isFlushingWork = false; | |||
| } | |||
|
|
|||
| function processRootScheduleInMicrotask() { | |||
| function processRootScheduleInImmediateTask() { | |||
| if (enableProfilerTimer && enableComponentPerformanceTrack) { | |||
| // Track the currently executing event if there is one so we can ignore this | |||
| // event when logging events. | |||
| trackSchedulerEvent(); | |||
There was a problem hiding this comment.
I had to restructure this a bit so that we have two separate callbacks depending on if we do the Scheduler_scheduleCallback pass or the microtask pass. Because we shouldn't call trackSchedulerEvent() if we're inside a microtask callback because that could mark a real event as if it was a scheduler event (and therefore hidden).
|
Comparing: 518d06d...75b0af0 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
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.
A common source of performance problems is due to cascading renders from calling
setStateinuseLayoutEffectoruseEffect. This marks the entry from the update to when we start the render as red and"Cascade"to highlight this.In addition to this case, there's another case where you call
setStatemultiple times in the same event causing multiple renders. This might be due to multipleflushSync, or spawned a microtasks from auseLayoutEffect. In theory it could also be from a microtask scheduled after the firstsetState. This one we can only detect if it's from an event that has awindow.eventsince otherwise it's hard to know if we're still in the same event.I decided against making a ping in a microtask considered a cascade. Because that should ideally be using the Suspense Optimization and so wouldn't be considered multi-pass.
We might consider making the whole render phase and maybe commit phase red but that should maybe reserved for actual errors. The "Blocked" phase really represents the
setStateand so will have the stack trace of the first update.