You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Digging into certain sources of slowness (e.g. slow memoization code) requires looking at the CPU flame chart. Unfortunately this predominantly consists of React internal frames, which can be convoluted if you are not familiar with React's source code.
One way to improve this would be to either filter out (remove) React internal frames or de-emphasize them visually in some other way. Because removing them would be more work, we should try dimming them instead. For example:
Ignore the colors above as it was just a quick mockup. Ideally the "internal" frames should be dimmer, not just grayscale.
Coloring internal frames is a simpler solution than filtering/hiding them, but how do we know which frames are internal? One way would be to capture an Error stack at the beginning and end of React internal modules (and then report it, along with other profiling data, via the user timing API).
Conceptually, it would work something like this:
/** @license React v18.0.0 * react.development.js * * Copyright (c) Facebook, Inc. and its affiliates. * * This source code is licensed under the MIT license found in the * LICENSE file in the root directory of this source tree. */'use strict';conststartOfModuleError=newError();// React module ...constendOfModuleError=newError();
However I'm not sure how we would actually do this across multiple modules, in strict mode, without polluting the global namespace. Maybe we could make use of the DevTools hook for this, although until #22529 lands, that seems a little hacky.
Anyway, assuming this information is present somewhere, it could be logged to the user timing API also so that it's persisted along with the other profiling data.
Lastly the Scheduling Profiler could read in this data and use it to determine which frames to color (based on whether or not they were within the start/stop ranges for the specified files).
The text was updated successfully, but these errors were encountered:
Follow up to #22578
Digging into certain sources of slowness (e.g. slow memoization code) requires looking at the CPU flame chart. Unfortunately this predominantly consists of React internal frames, which can be convoluted if you are not familiar with React's source code.
One way to improve this would be to either filter out (remove) React internal frames or de-emphasize them visually in some other way. Because removing them would be more work, we should try dimming them instead. For example:
Ignore the colors above as it was just a quick mockup. Ideally the "internal" frames should be dimmer, not just grayscale.
Coloring internal frames is a simpler solution than filtering/hiding them, but how do we know which frames are internal? One way would be to capture an Error stack at the beginning and end of React internal modules (and then report it, along with other profiling data, via the user timing API).
Conceptually, it would work something like this:
However I'm not sure how we would actually do this across multiple modules, in strict mode, without polluting the global namespace. Maybe we could make use of the DevTools hook for this, although until #22529 lands, that seems a little hacky.
Anyway, assuming this information is present somewhere, it could be logged to the user timing API also so that it's persisted along with the other profiling data.
Lastly the Scheduling Profiler could read in this data and use it to determine which frames to color (based on whether or not they were within the start/stop ranges for the specified files).
The text was updated successfully, but these errors were encountered: