Skip to content
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

Remove Calls to User Timing API #18417

Merged
merged 1 commit into from Mar 30, 2020
Merged

Remove Calls to User Timing API #18417

merged 1 commit into from Mar 30, 2020

Conversation

@gaearon
Copy link
Member

@gaearon gaearon commented Mar 28, 2020

This removes calls to the User Timing API in development.

There are several reasons why we want to do this.

  • Inaccurate timings. When we originally added it, we didn't have any profiling tools with React-specific knowledge. So we used what we could. Unfortunately, User Timings API was originally designed for cases like "loading page", and not for marking thousands of components. So it adds a lot of overhead. We've seen cases in hot paths where the User Timing API calls themselves account for over 30% of the rendering time. This means the measurements are skewed and often misleading. And since you can only get them in DEV mode, they're even worse. To solve this, we introduced React Profiler and special profiling buidls that give you much more accurate timings over a year ago, and we recommend using it.

  • Insufficient programmatic API. While User Timings API offers a way to observe measures, this API isn't well-suited for React's use cases either. Both in the open source community and internally at Facebook we've seen very complicated code attempting to parse data out of the performance markers. These approaches are fragile because they have to parse metadata out of strings. As an alternative, we added the <React.Profiler> component to gather measurements programmatically.

  • Bugs and maintenance burden. Supporting this has created a significant maintenance burden. The way the User Timing API is designed doesn't match how React works so we have to jump through a lot of hoops to play nice with it. Our support for it is pretty buggy and those bugs are very hard to fix. This is impeding refactors that would let us improve React's memory usage and make it faster, for example. Now that we have better alternatives, the cost of this is prohibitive compared to the value it provides.

Isn't This a Breaking Change?

This is not a breaking change because this utility has always been DEV-only. It is not enabled even in the Profiling builds. We reserve the right to change DEV-only behavior between versions. In this case, making this change would likely make React faster in development at the cost of some annoyance (learning to use a different and more accurate tool). There are clearly downsides, like losing the ability to see different markers side by side. Maybe we can solve them in the longer term, as described in next section.

Can We Add Them Back?

I think we could, eventually. The last version of the standard addressed some of the pain points, including the ability to attach metadata and (seemingly) the ability to specify custom timestamps. That might allow us to remove a lot of implementation complexity. However, we would still need to rip out this implementation since the new one would be significantly different. Additionally, we still wouldn't feel comfortable adding this back until we're sure that the performance penalties in major browsers have been addressed. For example, in the past we've seen these bugs unsolved for years.

Blockers

We have some blockers at FB where we rely on these in production as an experiment. That was a bad idea. See D20720369 and D20720332 for possible paths forward. We'll need to resolve that before merging.

@codesandbox
Copy link

@codesandbox codesandbox bot commented Mar 28, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit bf41bd2:

Sandbox Source
festive-feistel-swcy9 Configuration
@sizebot
Copy link

@sizebot sizebot commented Mar 28, 2020

Details of bundled changes.

Comparing: 5bd1bc2...bf41bd2

react-native-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactNativeRenderer-dev.js -2.2% -2.2% 649.65 KB 635.19 KB 140.37 KB 137.34 KB RN_OSS_DEV
ReactFabric-dev.js -2.3% -2.2% 631.51 KB 617.05 KB 135.96 KB 132.94 KB RN_OSS_DEV
ReactFabric-prod.js 0.0% 0.0% 258.68 KB 258.68 KB 44.85 KB 44.85 KB RN_OSS_PROD

react-art

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-art.development.js -2.7% -2.6% 535.8 KB 521.56 KB 115.29 KB 112.32 KB NODE_DEV
ReactART-dev.js -2.4% -2.3% 601.65 KB 587.2 KB 125.87 KB 122.94 KB FB_WWW_DEV
ReactART-prod.js 0.0% -0.0% 240.95 KB 240.95 KB 40.97 KB 40.97 KB FB_WWW_PROD
react-art.development.js -2.4% -2.2% 631.57 KB 616.5 KB 132.95 KB 130 KB UMD_DEV

react-test-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-test-renderer-shallow.production.min.js 0.0% 0.0% 12.91 KB 12.91 KB 3.93 KB 3.94 KB UMD_PROD
react-test-renderer.development.js -2.6% -2.6% 542.36 KB 528.13 KB 116.76 KB 113.75 KB NODE_DEV
ReactTestRenderer-dev.js -2.5% -2.5% 574.68 KB 560.3 KB 121.15 KB 118.16 KB FB_WWW_DEV
react-test-renderer.development.js -2.6% -2.6% 569.04 KB 553.98 KB 118.17 KB 115.13 KB UMD_DEV

react-dom

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-dom-test-utils.development.js 0.0% 0.0% 59.23 KB 59.23 KB 15.64 KB 15.64 KB UMD_DEV
ReactDOMTesting-profiling.js -0.0% -0.0% 403.86 KB 403.77 KB 73.47 KB 73.45 KB FB_WWW_PROFILING
react-dom-unstable-fizz.browser.development.js 0.0% +0.1% 3.34 KB 3.34 KB 1.26 KB 1.26 KB UMD_DEV
react-dom.profiling.min.js 0.0% 0.0% 122.02 KB 122.02 KB 38.32 KB 38.32 KB NODE_PROFILING
react-dom-server.node.development.js +0.1% +0.1% 127.53 KB 127.61 KB 34.09 KB 34.13 KB NODE_DEV
ReactDOMForked-dev.js -1.5% -1.4% 1002.92 KB 988.26 KB 222.78 KB 219.71 KB FB_WWW_DEV
ReactDOMForked-prod.js -2.6% -2.8% 422.61 KB 411.75 KB 76.68 KB 74.5 KB FB_WWW_PROD
react-dom.development.js -1.7% -1.5% 903.61 KB 888.53 KB 198.59 KB 195.63 KB UMD_DEV
ReactDOMForked-profiling.js -2.5% -2.8% 440.25 KB 429.43 KB 79.77 KB 77.51 KB FB_WWW_PROFILING
react-dom-server.browser.development.js +0.1% +0.1% 133.15 KB 133.23 KB 34.27 KB 34.32 KB UMD_DEV
react-dom.profiling.min.js 0.0% 0.0% 121.8 KB 121.8 KB 39.12 KB 39.12 KB UMD_PROFILING
ReactDOMTesting-dev.js +0.1% +0.1% 940.55 KB 941.55 KB 209.86 KB 210.09 KB FB_WWW_DEV
react-dom.development.js -1.7% -1.5% 860.04 KB 845.8 KB 196.17 KB 193.21 KB NODE_DEV
ReactDOMTesting-prod.js -0.0% -0.0% 403.86 KB 403.77 KB 73.47 KB 73.45 KB FB_WWW_PROD
react-dom-server.browser.development.js +0.1% +0.1% 126.32 KB 126.39 KB 33.84 KB 33.88 KB NODE_DEV
ReactDOM-dev.js -1.5% -1.4% 1002.92 KB 988.26 KB 222.78 KB 219.71 KB FB_WWW_DEV
ReactDOM-prod.js -2.6% -2.8% 422.61 KB 411.75 KB 76.68 KB 74.5 KB FB_WWW_PROD
ReactDOM-profiling.js -2.5% -2.8% 440.25 KB 429.43 KB 79.77 KB 77.51 KB FB_WWW_PROFILING
react-dom-test-utils.production.min.js 0.0% 0.0% 12.1 KB 12.1 KB 4.47 KB 4.47 KB NODE_PROD
react-dom-unstable-native-dependencies.development.js 0.0% 0.0% 54.71 KB 54.71 KB 14.13 KB 14.14 KB NODE_DEV

react-reconciler

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-reconciler.development.js -2.5% -2.4% 573.83 KB 559.6 KB 121.08 KB 118.13 KB NODE_DEV
react-reconciler-reflection.development.js +0.5% +0.9% 15.55 KB 15.62 KB 4.73 KB 4.77 KB NODE_DEV
react-reconciler-reflection.production.min.js 0.0% 🔺+0.1% 2.57 KB 2.57 KB 1.08 KB 1.08 KB NODE_PROD

Size changes (stable)

Generated by 🚫 dangerJS against bf41bd2

@sizebot
Copy link

@sizebot sizebot commented Mar 28, 2020

Details of bundled changes.

Comparing: 5bd1bc2...bf41bd2

react-test-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-test-renderer.development.js -2.6% -2.6% 569.07 KB 554 KB 118.18 KB 115.14 KB UMD_DEV
react-test-renderer.development.js -2.6% -2.6% 542.39 KB 528.15 KB 116.77 KB 113.76 KB NODE_DEV
ReactTestRenderer-dev.js -2.5% -2.5% 574.7 KB 560.32 KB 121.16 KB 118.17 KB FB_WWW_DEV

react-dom

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-dom-server.browser.development.js +0.1% +0.1% 134.74 KB 134.82 KB 34.47 KB 34.52 KB UMD_DEV
react-dom.profiling.min.js 0.0% 0.0% 126.22 KB 126.22 KB 39.52 KB 39.53 KB NODE_PROFILING
react-dom-unstable-fizz.browser.development.js 0.0% +0.1% 3.35 KB 3.35 KB 1.27 KB 1.27 KB UMD_DEV
ReactDOM-dev.js +0.1% +0.2% 957.07 KB 958.35 KB 212.74 KB 213.07 KB FB_WWW_DEV
react-dom-unstable-fizz.browser.development.js 0.0% +0.1% 2.95 KB 2.95 KB 1.18 KB 1.18 KB NODE_DEV
react-dom-test-utils.development.js 0.0% 0.0% 59.24 KB 59.24 KB 15.65 KB 15.65 KB UMD_DEV
react-dom-test-utils.production.min.js 0.0% -0.0% 12.26 KB 12.26 KB 4.55 KB 4.55 KB UMD_PROD
ReactDOMTesting-dev.js +0.1% +0.2% 913.79 KB 915.03 KB 203.96 KB 204.29 KB FB_WWW_DEV
react-dom-test-utils.development.js 0.0% 0.0% 54.7 KB 54.7 KB 15.03 KB 15.04 KB NODE_DEV
react-dom-server.node.development.js +0.1% +0.1% 129.05 KB 129.12 KB 34.3 KB 34.35 KB NODE_DEV
react-dom-test-utils.production.min.js 0.0% 0.0% 12.12 KB 12.12 KB 4.48 KB 4.48 KB NODE_PROD
react-dom-server.node.production.min.js 0.0% 0.0% 20.49 KB 20.49 KB 7.52 KB 7.52 KB NODE_PROD
react-dom-server.browser.development.js +0.1% +0.1% 127.83 KB 127.9 KB 34.05 KB 34.09 KB NODE_DEV
react-dom-server.browser.production.min.js 0.0% 0.0% 20.08 KB 20.08 KB 7.38 KB 7.38 KB NODE_PROD
react-dom.development.js -1.6% -1.5% 933.4 KB 918.33 KB 203.81 KB 200.85 KB UMD_DEV
react-dom.production.min.js 0.0% 0.0% 122.09 KB 122.09 KB 39.04 KB 39.04 KB UMD_PROD
ReactDOMForked-dev.js +0.1% +0.2% 957.07 KB 958.35 KB 212.74 KB 213.07 KB FB_WWW_DEV
react-dom.profiling.min.js 0.0% 0.0% 125.92 KB 125.92 KB 40.28 KB 40.28 KB UMD_PROFILING
react-dom.development.js -1.6% -1.5% 888.6 KB 874.36 KB 201.33 KB 198.37 KB NODE_DEV
react-dom-unstable-native-dependencies.development.js 0.0% 0.0% 54.72 KB 54.72 KB 14.14 KB 14.14 KB NODE_DEV
react-dom-unstable-fizz.node.development.js 0.0% +0.1% 3.69 KB 3.69 KB 1.34 KB 1.34 KB NODE_DEV

react-art

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactART-dev.js +0.2% +0.3% 573.58 KB 574.87 KB 120.2 KB 120.53 KB FB_WWW_DEV
react-art.development.js -2.3% -2.2% 651.84 KB 636.77 KB 136.62 KB 133.68 KB UMD_DEV
react-art.development.js -2.6% -2.5% 555.27 KB 541.03 KB 118.98 KB 116.01 KB NODE_DEV

react-native-renderer

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactNativeRenderer-dev.js -2.2% -2.1% 652.37 KB 637.98 KB 140.72 KB 137.74 KB RN_FB_DEV
ReactFabric-dev.js -2.3% -2.2% 631.52 KB 617.07 KB 135.96 KB 132.94 KB RN_OSS_DEV
ReactFabric-dev.js -2.3% -2.2% 634.24 KB 619.85 KB 136.3 KB 133.32 KB RN_FB_DEV
ReactFabric-prod.js 0.0% 0.0% 258.85 KB 258.85 KB 44.88 KB 44.89 KB RN_FB_PROD
ReactNativeRenderer-dev.js -2.2% -2.2% 649.66 KB 635.21 KB 140.37 KB 137.34 KB RN_OSS_DEV
ReactNativeRenderer-profiling.js 0.0% 0.0% 278.51 KB 278.51 KB 48.59 KB 48.59 KB RN_OSS_PROFILING

react-reconciler

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-reconciler-reflection.development.js +0.5% +0.9% 15.56 KB 15.64 KB 4.73 KB 4.77 KB NODE_DEV
react-reconciler-reflection.production.min.js 0.0% 🔺+0.1% 2.58 KB 2.58 KB 1.09 KB 1.09 KB NODE_PROD
react-reconciler.development.js -2.4% -2.4% 595.64 KB 581.4 KB 125.29 KB 122.32 KB NODE_DEV

Size changes (experimental)

Generated by 🚫 dangerJS against bf41bd2

@gaearon gaearon changed the title Remove Calls to User Timing API RFC: Remove Calls to User Timing API Mar 28, 2020
target._debugID = source._debugID;
target._debugIsCurrentlyTiming = source._debugIsCurrentlyTiming;
}
target._debugID = source._debugID;

This comment has been minimized.

@bvaughn

bvaughn Mar 28, 2020
Contributor

This should be in an if (__DEV__) block, I think?

Actually I think the few lines below it should be as well.

This comment has been minimized.

@gaearon

gaearon Mar 28, 2020
Author Member

This whole function is DEV-only so I'm not sure this is necessary.

This comment has been minimized.

@bvaughn

bvaughn Mar 28, 2020
Contributor

I realize the function is named assignFiberPropertiesInDEV but it's not actually gated anywhere to be DEV only.

This comment has been minimized.

@gaearon

gaearon Mar 28, 2020
Author Member

It's gated at the usage site. But I agree it would make sense to wrap its body too.

This comment has been minimized.

@bvaughn

bvaughn Mar 28, 2020
Contributor

Yeah, we usually gate in both places I think.

Not new to this PR, just something I noticed while looking at the code changes.

Copy link
Contributor

@bvaughn bvaughn left a comment

🎉

@gaearon gaearon changed the title RFC: Remove Calls to User Timing API Remove Calls to User Timing API Mar 30, 2020
@gaearon
Copy link
Member Author

@gaearon gaearon commented Mar 30, 2020

Internal blocker removed in D20720332.

@gaearon
Copy link
Member Author

@gaearon gaearon commented Mar 30, 2020

tldr: this is unfortunate but if we're going to re-add this, we'll need to do it differently and probably only support very recent browsers (Level 3 spec).

@gaearon gaearon merged commit bf30e37 into facebook:master Mar 30, 2020
31 checks passed
31 checks passed
ci/circleci: NODE_ENV_production_yarn_test_www Your tests passed on CircleCI!
Details
ci/circleci: NODE_ENV_production_yarn_test_www_variant Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_NODE_ENV_production_yarn_test_www Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_NODE_ENV_production_yarn_test_www_variant Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_build Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_build Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_build_prod Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_dom_fixtures Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_persistent Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_prod Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_www Your tests passed on CircleCI!
Details
ci/circleci: RELEASE_CHANNEL_stable_yarn_test_www_variant Your tests passed on CircleCI!
Details
ci/circleci: build_devtools_and_process_artifacts Your tests passed on CircleCI!
Details
ci/circleci: process_artifacts Your tests passed on CircleCI!
Details
ci/circleci: process_artifacts_experimental Your tests passed on CircleCI!
Details
ci/circleci: setup Your tests passed on CircleCI!
Details
ci/circleci: sizebot_experimental Your tests passed on CircleCI!
Details
ci/circleci: sizebot_stable Your tests passed on CircleCI!
Details
ci/circleci: yarn_build Your tests passed on CircleCI!
Details
ci/circleci: yarn_flow Your tests passed on CircleCI!
Details
ci/circleci: yarn_lint Your tests passed on CircleCI!
Details
ci/circleci: yarn_lint_build Your tests passed on CircleCI!
Details
ci/circleci: yarn_test Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_build Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_build_devtools Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_build_prod Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_prod Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_www Your tests passed on CircleCI!
Details
ci/circleci: yarn_test_www_variant Your tests passed on CircleCI!
Details
ci/codesandbox Building packages succeeded.
Details
@gaearon gaearon deleted the gaearon:no-perf branch Mar 30, 2020
@taneliang taneliang mentioned this pull request Jun 15, 2020
15 of 15 tasks complete
@julienw
Copy link

@julienw julienw commented Nov 20, 2020

Hey,
we just upgraded to React v17 in our project (the Firefox Profiler) and that's how I realized the UserTiming markers have been removed.

I know the ship has sailed for long on this, but I wanted to give a feedback on the removal of the user timing in the context of our project.

These user timing markers were super useful inside the Firefox Profiler, because we could see them on the same interface than other information (especially javascript sampling with stacks), and we could clearly see that some component took a long time to render, with its children.

Here are a few examples:
https://share.firefox.dev/3pWM1MK
https://share.firefox.dev/3nI34Qw

So the exactness of the timings wasn't as important as having a general idea of what's going on, before digging further.

I'm not so sure that using the standalone React Profiler is an improvement on that.
I'll look into using the new programmatic <Profiler> component that looks definitely interesting, and see if we can recreate the previous feature. Maybe that does exist elsewhere already?

Thanks

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Nov 20, 2020

Hey @julienw 👋

I'll look into using the new programmatic <Profiler> component that looks definitely interesting, and see if we can recreate the previous feature.

You can't recreate the user timing marks using <Profiler> (unless you tried to literally wrap every component in your app– which I wouldn't advise doing). The React DevTools profiling tool can do this because it has deep hooks into React itself.

I'm not so sure that using the standalone React Profiler is an improvement on that.

Can you elaborate on what pitfalls the React DevTools profiler has that makes it seem less useful to you? I'd love to learn more.

Also I'm wondering if you've seen this side work we've been doing on a new profiling tool? It doesn't yet support parsing Firefox profiles, but that could be added 😁 Especially if we had a little help 😉

Would you (or someone else on your team) be interested in hopping on a video chat about this sometime? Might be useful for us to each have a better sense of what each other is working on and how we might be able to help each other.

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Nov 20, 2020

I'll look into using the new programmatic <Profiler> component that looks definitely interesting, and see if we can recreate the previous feature.

You can't recreate the user timing marks using <Profiler> (unless you tried to literally wrap every component in your app– which I wouldn't advise doing). The React DevTools profiling tool can do this because it has deep hooks into React itself.

A quick note about this though: If you add selective <Profiler> wrappers to parts of your application, and then use the id, renderTime, and commitTime params passed to their callbacks, you can attribute parts of your flame graph in a way that might still be very helpful using the User Timing API level 3. I was just thinking about this myself the other day:

image

image

@julienw
Copy link

@julienw julienw commented Nov 20, 2020

Thanks for the quick answer!

You can't recreate the user timing marks using (unless you tried to literally wrap every component in your app– which I wouldn't advise doing).

Ah, thanks for telling me this. I initially thought we could get all updates by using a top-level <Profiler> component.
Maybe wrapping every component in a special mode (with a specific parameter, or enabling it from the console) would work :-)

Can you elaborate on what pitfalls the React DevTools profiler has that makes it seem less useful to you? I'd love to learn more.

While analyzing a profile, the first step is to focus on one interesting part. There are various ways to do this, but looking at the React markers is one common way when we work on a performance issue in a react application: we can double click on one of the markers, or select a group of markers, and only then move to another panel (probably the flame graph) to further analyze the performance issue.

Being a standalone profiler, with the Devtools profiler we can't do this easy dance of using it to focus on one specific part of a profile. But I admit I haven't been using it for some weeks now, so I may have missed new stuff.

Also I'm wondering if you've seen this side work we've been doing on a new profiling tool? It doesn't yet support parsing Firefox profiles, but that could be added. Especially if we had a little help wink

Ah ah I've seen it mentioned but didn't use it really yet :-)

Would you (or someone else on your team) be interested in hopping on a video chat about this sometime? Might be useful for us to each have a better sense of what each other is working on and how we might be able to help each other.

I'll talk about that internally, I believe that would be useful indeed! Helping make React apps faster is a clear goal for us :-)

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Nov 20, 2020

I initially thought we could get all updates by using a top-level <Profiler> component.

This would give you aggregate statistics for all components within the Profiler's subtree, but it wouldn't be broken down by component like it is in the flamegraph.

While analyzing a profile...

Not sure if I understand the work flow you're describing, but it sounds like maybe you start by scanning some zoomed-out version of the flame graph and then focus in on any of the parts that looks slow and use the user timing markers to see if it's related to React? The React Profiler can help show you what the slowest part(s) of your app are from its perspective, but admittedly it misses some of the surrounding context (e.g. other JS and how slow it is relative, or even how much time is spent by React itself outside of your components). This is one of the reasons I would love to see us get more hooks into the native Performance panel 😄

Let me know if/when you or anyone else from Moz wants to chat about this stuff. I'm always happy to make the time. 😄

@julienw
Copy link

@julienw julienw commented Nov 20, 2020

I was analyzing another problem today, and thought this could be another good example of how we were using the React Markers.
After zooming in to the right location, here I am with this stack chart:
image

With only the JS function names, everything is very generic. The React UserTiming markers were helping to understand what was going on.
... of course, our lack of sourcemap support (in our tool, I mean) doesn't help :-)

@bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Nov 20, 2020

React's implementation doesn't match most people's mental models for how components a React tree gets rendered. For example, it's iterative b'c of the requirement to yield and resume frequently without a lot of overhead. We may also render components in a seeming bizarre order because of APIs like Suspense. I think the React DevTools Profiler flame chart (which gets stitched back together in a way that's easy to think about and understand) is pretty useful in that regard, in a way that user timing markers just couldn't do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.