-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
[Fiber] Log Component Effects to Performance Track #30983
Merged
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
Opened by a member of the React Core Team
labels
Sep 17, 2024
Comparing: 15da917...ea5e88e 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
|
hoxyq
approved these changes
Sep 17, 2024
This lets us build up a tree of effects.
To ensure that parent comes first we subtrack a little bit when we bubble the start time.
It's getting a lot to duplicate.
sebmarkbage
force-pushed
the
performancemeasure3
branch
from
September 17, 2024 20:01
a3894dd
to
3eb822c
Compare
github-actions bot
pushed a commit
that referenced
this pull request
Sep 17, 2024
Stacked on #30981. Same as #30967 but for effects. This logs a tree of components using `performance.measure()`. In addition to the previous render phase this logs one tree for each commit phase: - Mutation Phase - Layout Effect - Passive Unmounts - Passive Mounts I currently skip the Before Mutation phase since the snapshots are so unusual it's not worth creating trees for those. The mechanism is that I reuse the timings we track for `enableProfilerCommitHooks`. I track first and last effect timestamp within each component subtree. Then on the way up do we log the entry. This means that we don't include overhead to find our way down to a component and that we don't need to add any additional overhead by reading timestamps. To ensure that the entries get ordered correctly we need to ensure that the start time of each parent is slightly before the inner one. DiffTrain build for [e1c2090](e1c2090)
sebmarkbage
added a commit
that referenced
this pull request
Sep 17, 2024
Stacked on #30983. This colors each component entry by its self time from light to dark depending on how long it took. If it took longer than a cut off we color it red (the error color). <img width="435" alt="Screenshot 2024-09-16 at 11 48 15 PM" src="https://github.com/user-attachments/assets/5d0bda83-6205-40e9-bec1-b81db2d48b2d">
github-actions bot
pushed a commit
that referenced
this pull request
Sep 17, 2024
Stacked on #30983. This colors each component entry by its self time from light to dark depending on how long it took. If it took longer than a cut off we color it red (the error color). <img width="435" alt="Screenshot 2024-09-16 at 11 48 15 PM" src="https://github.com/user-attachments/assets/5d0bda83-6205-40e9-bec1-b81db2d48b2d"> DiffTrain build for [8dfbd16](8dfbd16)
sebmarkbage
added a commit
to sebmarkbage/react
that referenced
this pull request
Nov 12, 2024
This reverts commit d3bf32a which was part of facebook#30983
sebmarkbage
added a commit
that referenced
this pull request
Nov 12, 2024
This reverts commit d3bf32a which was part of #30983 When you have very deep trees this trick can cause the top levels to skew way too much from the real numbers. Creating unbalanced trees. The bug should have been fixed in Chrome Canary now so that entries added later are sorted to go first which should've addressed this issue.
sebmarkbage
added a commit
that referenced
this pull request
Dec 18, 2024
In #30967 and #30983 I added logging of the just rendered components and the effects. However this didn't consider the special Offscreen passes. So this adds the same thing to those passes. Log component effect timings for disconnected/reconnected offscreen subtrees. This includes initial mount of a Suspense boundary. Log component render timings for reconnected and already offscreen offscreen subtrees.
github-actions bot
pushed a commit
that referenced
this pull request
Dec 18, 2024
In #30967 and #30983 I added logging of the just rendered components and the effects. However this didn't consider the special Offscreen passes. So this adds the same thing to those passes. Log component effect timings for disconnected/reconnected offscreen subtrees. This includes initial mount of a Suspense boundary. Log component render timings for reconnected and already offscreen offscreen subtrees. DiffTrain build for [6a4b46c](6a4b46c)
github-actions bot
pushed a commit
that referenced
this pull request
Dec 18, 2024
In #30967 and #30983 I added logging of the just rendered components and the effects. However this didn't consider the special Offscreen passes. So this adds the same thing to those passes. Log component effect timings for disconnected/reconnected offscreen subtrees. This includes initial mount of a Suspense boundary. Log component render timings for reconnected and already offscreen offscreen subtrees. DiffTrain build for [6a4b46c](6a4b46c)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 18, 2024
…ok#31788) In facebook#30967 and facebook#30983 I added logging of the just rendered components and the effects. However this didn't consider the special Offscreen passes. So this adds the same thing to those passes. Log component effect timings for disconnected/reconnected offscreen subtrees. This includes initial mount of a Suspense boundary. Log component render timings for reconnected and already offscreen offscreen subtrees. DiffTrain build for [6a4b46c](facebook@6a4b46c)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Dec 18, 2024
…ok#31788) In facebook#30967 and facebook#30983 I added logging of the just rendered components and the effects. However this didn't consider the special Offscreen passes. So this adds the same thing to those passes. Log component effect timings for disconnected/reconnected offscreen subtrees. This includes initial mount of a Suspense boundary. Log component render timings for reconnected and already offscreen offscreen subtrees. DiffTrain build for [6a4b46c](facebook@6a4b46c)
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.
Stacked on #30981. Same as #30967 but for effects.
This logs a tree of components using
performance.measure()
.In addition to the previous render phase this logs one tree for each commit phase:
I currently skip the Before Mutation phase since the snapshots are so unusual it's not worth creating trees for those.
The mechanism is that I reuse the timings we track for
enableProfilerCommitHooks
. I track first and last effect timestamp within each component subtree. Then on the way up do we log the entry. This means that we don't include overhead to find our way down to a component and that we don't need to add any additional overhead by reading timestamps.To ensure that the entries get ordered correctly we need to ensure that the start time of each parent is slightly before the inner one.