New implementation of PerformanceObserver and related APIs (fixes #45122)

[robik]

Summary:

Fix #45122.

performance.mark is currently O(1) but performance.clearMark is O(n) (being n the number of entries in the buffer), which makes this operation very slow.

Changes overview

• Created new PerformanceEntryBuffer abstraction with the following subtypes, that differ on how entries are stored:
  • PerformanceEntryCircularBuffer - stores them in a ring buffer that was already implemented, removed key lookup cache (BoundedConsumableBuffer)
  • PerformanceEntryKeyedBuffer - stores them in a unordered_map, allowing for faster retrieval by type
  • PerformanceEntryLinearBuffer - a simple infinite buffer based on std::vector, currently used in a PerformanceObserver
• Created PerformanceObserver abstraction on native side.
• Created PerformanceObserverRegistry that collects active observers and forwards entries to observers that should retrieve them
• Moved some method implementations to .cpp files to reduce potential compilation time slowdown. As the PerformanceEntryReporter can be included from anywhere in the code, it will be beneficial to make header files as light as possible.
• Add comments to methods that note which standard is the method from/for.
• Added some [[nodiscard]] attributes
• Since the logic of routing entries to observers is moved to native side, JS side of the code got much simplified
• If ever needed, PerformanceObserver can be created from native-side

Standards covered:

• https://www.w3.org/TR/performance-timeline
• https://www.w3.org/TR/event-timing/
• https://w3c.github.io/timing-entrytypes-registry
• https://w3c.github.io/user-timing/

Changelog:

[GENERAL] [CHANGED] - Refactored performance-timeline module, which should improve performance of performance.clearMarks and performance.clearMeasures

Test Plan:

n/a

[robik]

Pushed early changes for approach review. Still working on updating TurboModule and its spec to match new API.

[robik]

Ready for an early review. Will undo changes related to exposing Performance TurboModule and still needs some testing from my side.

[rubennorte]

This is a larger refactor than I was expecting, but I like the direction we're taking here. I made an initial pass on the PR (please forgive the amount of comments, this is very large). Please let me know what you think, and thanks so much for this!

[rubennorte]

We don't want to enable this by default yet, until we've had a chance to test it thoroughly at Meta first. Please revert this for the PR (I understand you still need it to test it).

[rubennorte]

Please add the comment about this being temporary as well :P

[robik]

@rubennorte I've allowed myself to resolve comments that I think are corrected :) The remaining ones I still need some input.
Sorry for large batch of changes again, but I think I simplified a lot of things.

FYI: still not fully tested on my side 😅

[rubennorte]

Please add the comment about this being temporary as well :P

[rubennorte]

Do these need to be public?

[robik]

It needs to be accessed from EntryReporter to validate if the entry should be added. I can make it protected, but then I'd need to make it a friend of EntryReporter which I'd avoid. As an alternative I could move the login into buffer itself, but that was just moved out of it :D

[rubennorte]

I don't think we need durationThreshold here. We can just define it in the buffer for event entry types.

Regarding droppedEntriesCount, there's no reason to have them per buffer AFAIK, so we could make add return a boolean and then have a single count in the entry reporter, so you don't even have to iterate over each buffer. It's a bit simpler IMHO.

Actually, we need to keep them separate per buffer because the reported number is only for the entry types that the observer is observing. Please ignore this last comment :)

[facebook-github-bot]

@rubennorte has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[rubennorte]

This shouldn't be exposed to JS because these are always emitted from native.

[robik]

I exposed them for unittests 😅

[rubennorte]

Maybe make the name more explicit (e.g.: testOnly_logEvent).

[rubennorte]

This should be a set of types that we need to report dropped entries. This should also work if we do this:

observer.observe({type: 'mark', buffered: true}); // report marks until this point and report dropped ones
observer.observer({type: measure', buffered: true}); // same, but for this time and until this moment

[robik]

We iterate over observer types below, and the flag is reset after each observe. So it should work as mentioned (considering observe resets entries, not adds more)

[rubennorte]

I think we're not handling the timing of that correctly. We're determining the number of dropped entries when the callback is executed, not when we "dump" all the entries in the observer buffer. Also, if we execute the code I shared in previous example, we'd be dropping all the existing entries in the observer buffer because we just reassign it. We just append those and determine dropped entries at the time of observation.