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 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]
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:
[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
Ruslan Shestopalyuk
Christoph Purrer