react/packages/react-devtools-shared/src/PerformanceLoggingUtils.js

108 lines
2.3 KiB
JavaScript
Raw Normal View History

/**
* 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.
*
* @flow strict-local
*/
import {__PERFORMANCE_PROFILE__} from './constants';
DevTools: Improve named hooks network caching (#22198) While testing the recently-launched named hooks feature, I noticed that one of the two big performance bottlenecks is fetching the source file. This was unexpected since the source file has already been loaded by the page. (After all, DevTools is inspecting a component defined in that same file.) To address this, I made the following changes: - [x] Keep CPU bound work (parsing source map and AST) in a worker so it doesn't block the main thread but move I/O bound code (fetching files) to the main thread. - [x] Inject a function into the page (as part of the content script) to fetch cached files for the extension. Communicate with this function using `eval()` (to send it messages) and `chrome.runtime.sendMessage()` to return its responses to the extension). With the above changes in place, the extension gets cached responses from a lot of sites- but not Facebook. This seems to be due to the following: * Facebook's response headers include [`vary: 'Origin'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary). * The `fetch` made from the content script does not include an `Origin` request header. To reduce the impact of cases where we can't re-use the Network cache, this PR also makes additional changes: - [x] Use `devtools.network.onRequestFinished` to (pre)cache resources as the page loads them. This allows us to avoid requesting a resource that's already been loaded in most cases. - [x] In case DevTools was opened _after_ some requests were made, we also now pre-fetch (and cache in memory) source files when a component is selected (if it has hooks). If the component's hooks are later evaluated, the source map will be faster to access. (Note that in many cases, this prefetch is very fast since it is returned from the disk cache.) With the above changes, we've reduced the time spent in `loadSourceFiles` to nearly nothing.
2021-09-02 02:10:07 +08:00
const supportsUserTiming =
typeof performance !== 'undefined' &&
typeof performance.mark === 'function' &&
typeof performance.clearMarks === 'function';
const supportsPerformanceNow =
typeof performance !== 'undefined' && typeof performance.now === 'function';
function mark(markName: string): void {
DevTools: Improve named hooks network caching (#22198) While testing the recently-launched named hooks feature, I noticed that one of the two big performance bottlenecks is fetching the source file. This was unexpected since the source file has already been loaded by the page. (After all, DevTools is inspecting a component defined in that same file.) To address this, I made the following changes: - [x] Keep CPU bound work (parsing source map and AST) in a worker so it doesn't block the main thread but move I/O bound code (fetching files) to the main thread. - [x] Inject a function into the page (as part of the content script) to fetch cached files for the extension. Communicate with this function using `eval()` (to send it messages) and `chrome.runtime.sendMessage()` to return its responses to the extension). With the above changes in place, the extension gets cached responses from a lot of sites- but not Facebook. This seems to be due to the following: * Facebook's response headers include [`vary: 'Origin'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary). * The `fetch` made from the content script does not include an `Origin` request header. To reduce the impact of cases where we can't re-use the Network cache, this PR also makes additional changes: - [x] Use `devtools.network.onRequestFinished` to (pre)cache resources as the page loads them. This allows us to avoid requesting a resource that's already been loaded in most cases. - [x] In case DevTools was opened _after_ some requests were made, we also now pre-fetch (and cache in memory) source files when a component is selected (if it has hooks). If the component's hooks are later evaluated, the source map will be faster to access. (Note that in many cases, this prefetch is very fast since it is returned from the disk cache.) With the above changes, we've reduced the time spent in `loadSourceFiles` to nearly nothing.
2021-09-02 02:10:07 +08:00
if (supportsUserTiming) {
performance.mark(markName + '-start');
}
}
function measure(markName: string): void {
DevTools: Improve named hooks network caching (#22198) While testing the recently-launched named hooks feature, I noticed that one of the two big performance bottlenecks is fetching the source file. This was unexpected since the source file has already been loaded by the page. (After all, DevTools is inspecting a component defined in that same file.) To address this, I made the following changes: - [x] Keep CPU bound work (parsing source map and AST) in a worker so it doesn't block the main thread but move I/O bound code (fetching files) to the main thread. - [x] Inject a function into the page (as part of the content script) to fetch cached files for the extension. Communicate with this function using `eval()` (to send it messages) and `chrome.runtime.sendMessage()` to return its responses to the extension). With the above changes in place, the extension gets cached responses from a lot of sites- but not Facebook. This seems to be due to the following: * Facebook's response headers include [`vary: 'Origin'`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary). * The `fetch` made from the content script does not include an `Origin` request header. To reduce the impact of cases where we can't re-use the Network cache, this PR also makes additional changes: - [x] Use `devtools.network.onRequestFinished` to (pre)cache resources as the page loads them. This allows us to avoid requesting a resource that's already been loaded in most cases. - [x] In case DevTools was opened _after_ some requests were made, we also now pre-fetch (and cache in memory) source files when a component is selected (if it has hooks). If the component's hooks are later evaluated, the source map will be faster to access. (Note that in many cases, this prefetch is very fast since it is returned from the disk cache.) With the above changes, we've reduced the time spent in `loadSourceFiles` to nearly nothing.
2021-09-02 02:10:07 +08:00
if (supportsUserTiming) {
performance.mark(markName + '-end');
performance.measure(markName, markName + '-start', markName + '-end');
}
}
function now(): number {
if (supportsPerformanceNow) {
return performance.now();
}
return Date.now();
}
export async function withAsyncPerfMeasurements<TReturn>(
markName: string,
callback: () => Promise<TReturn>,
onComplete?: number => void,
): Promise<TReturn> {
const start = now();
if (__PERFORMANCE_PROFILE__) {
mark(markName);
}
const result = await callback();
if (__PERFORMANCE_PROFILE__) {
measure(markName);
}
if (onComplete != null) {
const duration = now() - start;
onComplete(duration);
}
return result;
}
export function withSyncPerfMeasurements<TReturn>(
markName: string,
callback: () => TReturn,
onComplete?: number => void,
): TReturn {
const start = now();
if (__PERFORMANCE_PROFILE__) {
mark(markName);
}
const result = callback();
if (__PERFORMANCE_PROFILE__) {
measure(markName);
}
if (onComplete != null) {
const duration = now() - start;
onComplete(duration);
}
return result;
}
export function withCallbackPerfMeasurements<TReturn>(
markName: string,
callback: (done: () => void) => TReturn,
onComplete?: number => void,
): TReturn {
const start = now();
if (__PERFORMANCE_PROFILE__) {
mark(markName);
}
const done = () => {
if (__PERFORMANCE_PROFILE__) {
measure(markName);
}
if (onComplete != null) {
const duration = now() - start;
onComplete(duration);
}
};
return callback(done);
}