Use console.timeStamp instead of performance.measure in Component Performance Track #32736
Conversation
This file contains hidden or 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
github-actions
bot
added
the
React Core Team
sebmarkbage
force-pushed
the
consoletimestamp
branch
from
e6a16c8 to
1640275
Compare
eps1lon
approved these changes
Mar 26, 2025
rickhanlonii
approved these changes
Apr 2, 2025
sebmarkbage
force-pushed
the
consoletimestamp
branch
from
1640275 to
da665e1
Compare
sebmarkbage
force-pushed
the
consoletimestamp
branch
from
da665e1 to
887e0e0
Compare
sebmarkbage
force-pushed
the
consoletimestamp
branch
from
887e0e0 to
50781c2
Compare
Except for errors in DEV where we use the properties extension.
If we use the same start/end time we get the same effect.
sebmarkbage
force-pushed
the
consoletimestamp
branch
from
50781c2 to
3bc3e8a
Compare
|
Chrome 136 is now rolling out in the stable channel so we can land this. |
sebmarkbage
added a commit
that referenced
this pull request
Apr 30, 2025
…2809) Stacked on #32736. That way you can find the owner stack of each component that rerendered for context. In addition to the JSX callsite tasks that we already track, I also added tracking of the first `setState` call before rendering. We then run the "Update" entries in that task. That way you can find the callsite of the first setState and therefore the "cause" of a render starting by selecting the "Update" track. Unfortunately this is blocked on bugs in Chrome that makes it so that these stacks are not reliable in the Performance tab. It basically just doesn't work.
github-actions bot
pushed a commit
that referenced
this pull request
Apr 30, 2025
…2809) Stacked on #32736. That way you can find the owner stack of each component that rerendered for context. In addition to the JSX callsite tasks that we already track, I also added tracking of the first `setState` call before rendering. We then run the "Update" entries in that task. That way you can find the callsite of the first setState and therefore the "cause" of a render starting by selecting the "Update" track. Unfortunately this is blocked on bugs in Chrome that makes it so that these stacks are not reliable in the Performance tab. It basically just doesn't work. DiffTrain build for [62960c6](62960c6)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Apr 30, 2025
…cebook#32809) Stacked on facebook#32736. That way you can find the owner stack of each component that rerendered for context. In addition to the JSX callsite tasks that we already track, I also added tracking of the first `setState` call before rendering. We then run the "Update" entries in that task. That way you can find the callsite of the first setState and therefore the "cause" of a render starting by selecting the "Update" track. Unfortunately this is blocked on bugs in Chrome that makes it so that these stacks are not reliable in the Performance tab. It basically just doesn't work. DiffTrain build for [62960c6](facebook@62960c6)
This was referenced May 5, 2025
This was referenced May 12, 2025
This was referenced May 19, 2025
16 tasks
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.
This is a new extension that Chrome added to the existing
console.timeStampsimilar to the extensions added toperformance.measure. This one should be significantly faster because it doesn't have the extra object indirection, it doesn't return aPerformanceMeasureentry and doesn't register itself with the global system of entries.I also use
performance.measurein DEV for errors since we can attach the error to thepropertiesextension which doesn't exist forconsole.timeStamp.A downside of using this API is that there's no programmatic API for the site itself to collect its own logs from React. Which the previous allowed us to use the standard
performance.getEntries()for. The recommendation instead will be for the site to patchconsole.timeStampif it wants to collect measurements from React just like you're recommended to patchconsole.errororfetchor whatever to collect other instrumentation metrics.This extension works in Chrome canary but it doesn't yet work fully in Chrome stable. We might want to wait until it has propagated to Chrome to stable. It should be in Chrome 136.