Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36152
[Changelog][Internal]
By [the W3C standard](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), `PerformanceObserver.observer` can optionally take a `durationThreshold` option, so that only entries with duration larger than the threshold are reported.
This diff adds support for this on the RN side, as well as unit tests for this feature on the JS side.
NOTE: The standard suggests that default value for this is 104s. I left it at 0 for now, as for the RN use cases t may be to too high (needs discussion).
Reviewed By: rubennorte
Differential Revision: D43154319
fbshipit-source-id: 0f9d435506f48d8e8521e408211347e8391d22fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36181
[Changelog][Internal]
Implements EventCounts API (`Performance.eventCounts`) for Web Performance, according to the W3C standard, see the specs here: https://www.w3.org/TR/event-timing/#eventcounts
The rationale for why we need it is to support some advanced metrics computations, such as a ratio of "slow events" to total event count, per event type.
Reviewed By: rubennorte
Differential Revision: D43285073
fbshipit-source-id: 2c53d04d9a57c1301e37f2a5879072c8d33efbbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36116
[Changelog][Internal]
Add a minimal/reference JavaScript implementation for NativePerformanceObserver - the purpose is both unit testing (JS and native sides separately) and potentially shimming the part of functionality that is not dependent on native side.
This is both a setup for adding general unit tests for the Performance* APIs, but also to be able to do non-trivial changes on JS side for WebPerformance (such as in (D43154319).
Reviewed By: rubennorte
Differential Revision: D43167392
fbshipit-source-id: 213d9534d810dece1dd464f910e92e08dbf39508
Summary:
[Changelog][Internal]
`NativePerformanceObserver` TurboModule API would get the type for performance entries as strings in one direction (`start/stopReporting`) and as integers in another direction (inside `RawPerformanceEntry`, for optimization on the native side).
This makes is symmetrical and consistent, all the conversions are now handled on the JS side.
Reviewed By: christophpurrer
Differential Revision: D43236466
fbshipit-source-id: 08e1b62df90e6d26a11577d6b6b1d91a6bce8339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35771
[Changelog][Internal]
Based on the internal discussion, we don't want to report `first-input` event types for RN (just use plain `event` instead), in the way that [Event Timing API standard suggests](https://www.w3.org/TR/event-timing), as this is doesn't have that clear semantics in the context of RN, also to keep it simpler.
Reviewed By: rubennorte
Differential Revision: D42341923
fbshipit-source-id: eff2487dee17ef082604e4c807b4d41485328114
Summary:
Changelog: [Internal]
This adds definition of `PerformanceEventTiming` interface, according to the W3C standard, so that [event timing](https://www.w3.org/TR/event-timing) data can be reported from native (the C++ part is in the next diff).
See here: https://www.w3.org/TR/event-timing/#performanceeventtiming
Reviewed By: christophpurrer
Differential Revision: D42279486
fbshipit-source-id: 0dfbcd6e5a08fc1b89651bd35b24fb4e731f8b05
Summary:
Extends the WebPerformance API with ability to report events, [according to the standard](https://www.w3.org/TR/event-timing/#sec-performance-event-timing).
This is an API-only change, the actual reporting comes in a separate diff, to simplify reviewing.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42097695
fbshipit-source-id: d8b468ffed50c1c3d889151df5e8ca644d6e1a68
Summary:
Prevents scenarios when internal performance buffer may grow indefinitely (e.g. due to a broken logging), communicating back to `PerformanceObserver` the corresponding amount of dropped entries, `droppedEntriesCount`, [according to the standard](https://w3c.github.io/performance-timeline/#dom-performanceobservercallbackoptions-droppedentriescount).
NOTE: The backwards compatibility check is failing, which is an orthogonal issue. I am looking into it and won't land this one before it is sorted.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008409
fbshipit-source-id: 40d30e44d39e643bfb58a6254572823cb2b3b8df
Summary:
Now that D42097191 allows it, get rid of unused API in the related WebPerformance native modules (these were kept there only to pacify the backwards compatibility checks).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42037757
fbshipit-source-id: 5f5e7e76722cade9e730aba037f9e8ab51fc16d9
Summary:
Our implementation of `PerformanceObserver.prototype.observe` diverges a little bit from the [spec](https://w3c.github.io/performance-timeline/#dom-performanceobserver-observe) regarding the behavior when calling it multiple times. E.g.:
1. We don't throw errors if both `type ` and `entryTypes` are passed.
2. We don't throw errors if neither `type ` nor `entryTypes` are passed.
3. We don't throw errors if we call observe with `type` and we call again later with `entryTypes`, and vice versa.
4. The logic to consolidate entry types in subsequent observe calls is incorrect.
This fixes those issues and also applies some minor naming improvements.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D41872269
fbshipit-source-id: 9a6b485f4ef2f479c8b6f0307012322f65a11879
Summary:
Changelog: [Internal]
This adds JS side implementation (including the API) for the `Performance.measure` functionality, [as described in the corresponding standard](https://www.w3.org/TR/user-timing/#measure-method).
The JS part is separated from the C++ implementation (further down the stack) to help the review being more focused.
Reviewed By: mdvacca
Differential Revision: D41733190
fbshipit-source-id: 72b69f6bb332aed4b9477a186b0e818b62009220
Summary:
[Changelog][Internal]
Addresses the corresponding TODO in code, to make sure that PerformanceObserver.observe may be called multiple times with different entry types to observe.
Reviewed By: christophpurrer
Differential Revision: D41686237
fbshipit-source-id: 4287f63f7e71e5b1056d30ed616149841ba4f892
Summary:
[Changelog][Internal]
The name corresponds more precisely to what the method does.
Reviewed By: christophpurrer
Differential Revision: D41686205
fbshipit-source-id: 36c47b57fdeb757515cd14b890f38247f7fe8d02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35526
[Changelog][Internal]
This closes the full loop according to the [technical design](https://fb.quip.com/MdqgAk1Eb2dV) of the WebPerf API implementation, with the main components and the working central data flow in place.
The next step is to add some buffering/throttling, as in this diff we just spawn an idle-priority task after every performance entry coming (even though they still naturally do come in batches, because they manage to accumulate before the task is executed).
Reviewed By: christophpurrer
Differential Revision: D41496082
fbshipit-source-id: 5fd4cf22e75806f7bc98d1d1b6691596ccadf8b9
Summary:
[Changelog][Internal]
Adds API definition for [Performance.mark](https://www.w3.org/TR/user-timing/#mark-method) support.
This is a bare bone implementation, that just logs events on the native side. The next step is the native logic for queuing, flushing etc.
Note that here I route both JS and native marks to native for now, for simplicity sake - ultimately this may not be what we want, as it may be more efficient to process marks, logged from JS, on the JS side.
Reviewed By: rubennorte
Differential Revision: D41472148
fbshipit-source-id: bdf2b182b8472a71a5500235849bca5af1c2f360
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35226
Changelog: [Internal]
This adds scaffolding for the C++ side of NativePerformanceObserver module.
Thanks to christophpurrer for helping set this up, as this is the first one of this kind inside core/OSS.
Reviewed By: rubennorte
Differential Revision: D41028555
fbshipit-source-id: 4acf0e71a254a42044cbbe5f94f40938342c6aa2
Summary:
[Changelog][Internal]
This adds module specs for the native part of PerformanceObserver, as well as the interaction logic vs the NativePerformanceObserver API.
See https://fb.quip.com/MdqgAk1Eb2dV for more detail.
Reviewed By: rubennorte
Differential Revision: D40897006
fbshipit-source-id: 77475f21dad9ee9dbe15df5a989eb08d314e6db2
Summary:
[Changelog][Internal]
This is to prevent an accidental use of PerformanceObserver while it's still a work in progress.
PerformanceObserver is also moved into a dedicated folder, `Libraries/WebPerformance`.
Reviewed By: rubennorte
Differential Revision: D40978749
fbshipit-source-id: 09645a95bed72902870ebc00c1b4a3d81ab4c829
Ruslan Shestopalyuk
Rubén Norte