Summary:
Makes sure that we don't spam too often the JS performance entry reporting callback, which further dispatches entries to `PerformanceObserver` instances.
The logic is as following:
* ~~~If internal buffer of entries reaches the limit, we schedule the callback (with background priority)~~~
*~~~ Once the callback is processed, we schedule the next flush after a timeout of 500ms, this will also be scheduled from native with background priority~~~
* ~~~Whenever new performance type starts to be observed, we also schedule the callback, in order to prime the above~~~
* Schedule the flush with low priority, whenever there is the first entry coming into an empty buffer, and rely on the Scheduler to "do the right thing" when asked to flush it with background priority and not doo it exceedingly often (see the prolonged discussion)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D41875085
fbshipit-source-id: 368b525203215350ceabb43d5e9e8e3bd5242aca
Summary:
Changelog: [Internal]
This implements the C++ side logic of handling `Performance.measure` calls.
Since measures may refer to earlier logged marks by name, we need to keep track of the former. I also use a fixed size (circular) buffer to prevent the marks from piling forever.
Also adds implementation of clearing marks/measures, as per standard.
Reviewed By: mdvacca
Differential Revision: D41756928
fbshipit-source-id: 19dce28d6af4c5646274e6d5db20b41869282780
Summary:
[Changelog][Internal]
The NativePerformance module functionality corresponds to the [timing extensions of the Performance API standard interface](https://www.w3.org/TR/user-timing/#extensions-performance-interface).
As this is logically separate from `PerformanceObserver` (which may exist without it), it makes sense to have it as a different native module, so there is no coupling between both.
Reviewed By: christophpurrer
Differential Revision: D41690145
fbshipit-source-id: 7443f4c51f54cc2fdddbdb2e89f9a1fa457ab280
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
Ruslan Shestopalyuk