Summary:
This diff adds the `performance.reactNativeStartupTiming` API to the performance global object for RN. This property does not exist in web, and we are free to make up our own list of properties in the startup metrics to track RN app startup process. In our case, we have the following six properties to begin with (we may extend and add more to this list in the future):
```
- `(start|end)Time`: The time ‘zero’ for the startup timing and the end of app startup. RN has no knowledge of app start time, which will be provided by the platform. The `endTime` will be the time when the first JS bundle finishes executing (Note that RN supports multiple JS bundles, which can be loaded async)
- `executeJavaScriptBundleEntryPoint(Start|End)`: The time for RN to execute the JS entry point (and finish all sync job)
```
Changelog:
[General][Added] - Add new JS performance API to support getting RN app startup timings
Reviewed By: rshest
Differential Revision: D43326564
fbshipit-source-id: 7b4c7cae70ff64ba1714a1630cd5e183df6c06b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36314
## Changelog:
[Internal] - Added support for W3C Performance API extension (Performance,getEntries*)
See [here for the details](https://www.w3.org/TR/performance-timeline/#extensions-to-the-performance-interface).
This only supports `mark` and `measure` performance entry types (not `events`, as those are not supported by browsers either, they recommend using the `PerformanceObserver` API instead).
From the implementation perspective, we already maintained persistent buffer for `mark` entry types, which was required in order to look up measures.
The buffer is circular, limited to 1K entries by default.
I basically mimic the same behavior for `measure` entry types as well, since it's the simplest way of doing it at this point,
If we happen to want adding some other entry types that would be available via `Performance.getEntries*` API in the future, we may want to iterate on the internal data structures representation inside `PerformanceEntryReporter`, but for now I believe this approach should work just fine, and whatever changes we may want to do will be purely internal implementation detail.
Reviewed By: rubennorte
Differential Revision: D43625488
fbshipit-source-id: dd315b3f8488e910749a8e2a4158246e94d76f99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36312
## Changelog:
[Internal] -
`clearMarks` and `clearMeasures` methods are incidental to the `NativePerformance` TurboModule functionality, as in reality this responsibility belongs more on the `NativePerformanceObserver` and `PerformanceEntryReporter` side.
This is something that [the standard indirectly suggests](https://www.w3.org/TR/user-timing/#clearmarks-method) as well (referencing [performance entry buffer](https://www.w3.org/TR/performance-timeline/#dfn-performance-entry-buffer)).
The new implementation should be also a little bit more efficient, as it avoids calling the predicate for each entry.
Finally (and frankly, the main reason for this change, from my perspective), it will simplify mocking/testing the JS part of the PerfAPI code.
Reviewed By: rubennorte
Differential Revision: D43621174
fbshipit-source-id: c4217a0da1d8ecbce797240627f7b4f057d85b97
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:
This diff adds new performance API `memory`, which is a read-only property that gets the current JS heap size from native side.
Note that the JSI API returns an unordered map with unknown list of memory information, which is different from the [web spec](https://fburl.com/p0vpbt33). We may enforce specific memory info type on the JSI API so that it can be properly translate to the web spec.
- Update the JS spec
- Update Native implementation and return memory information with JSI API `jsi::instrumentation()::getHeapInfo()`
- Add native performance module to catalyst package
Changelog:
[General][Added] - Add performance memory API with native memory Info
Reviewed By: rubennorte
Differential Revision: D43137071
fbshipit-source-id: 319f1a6ba78fce61e665b00849ecf2579094af83
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:
Makes sure that the global (standard) `performance` instance is initialized to still both provide `Performance.now()` as before, but also allows for the newly implemented functionality from the WebPerf API, such as marks/measures.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42017812
fbshipit-source-id: ddbe79e91b45a84871de94018305f2a4536ada4b
Summary:
We're currently showing warnings when we call `performanceObserver.observe` and the native module for performance observers isn't available, but we don't do the same for `performance.mark`, `performance.measure`, etc.
This adds the warning in those cases.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D41872270
fbshipit-source-id: d720580b930550f27c827a58243579c42a4f6da9
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]
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
Xin Chen
Ruslan Shestopalyuk
Rubén Norte