Implement specialized container type for performance entry buffering #36726

rshest · 2023-03-30T16:48:34Z

Summary:

Changelog:

[Internal] -

This implements (together with unit tests) a generic container type with the following properties:

It can only grow up to a specified max size
It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element)
The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer
Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times

The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not).

In fact, this container is factoring that behavior, which is already there in PerformanceEntryObserver (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type.

Differential Revision: D44544057

facebook-github-bot · 2023-03-30T16:49:07Z

This pull request was exported from Phabricator. Differential Revision: D44544057

facebook-github-bot · 2023-03-30T16:57:50Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: c61b2078619269b11c1262b519235da8a14bb473

analysis-bot · 2023-03-30T17:21:44Z

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,569,009	+0
android	hermes	armeabi-v7a	7,883,400	+0
android	hermes	x86	9,050,927	+0
android	hermes	x86_64	8,905,954	+0
android	jsc	arm64-v8a	9,167,731	+0
android	jsc	armeabi-v7a	8,358,132	+0
android	jsc	x86	9,224,398	+0
android	jsc	x86_64	9,482,236	+0

Base commit: 8b72c33
Branch: main

facebook-github-bot · 2023-03-30T20:19:25Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: ada66120df58639b182ae145305ecb00855f31d6

facebook-github-bot · 2023-03-30T21:37:30Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: b9db809351310365cdeaa27a4782c20648220218

facebook-github-bot · 2023-03-30T22:06:41Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 22c5fa2cc52590da1e6e3de2bd47ab98729ecfc8

Pranav-yadav · 2023-03-31T06:44:30Z

packages/react-native/Libraries/WebPerformance/BoundedConsumableBuffer.h

+   * size and how many are there unconsumed elements.
+   */
+  PushStatus add(const T &&el) {
+    if (entries_.size() < maxSize_) {


This overall is an awesome implementation. 🙌
Before proceeding, I'm just here to learn.
I had a question though; specifically with this method (add);

What if the caller want's the value being overwritten (in that case), to be returned from add?

I.e. Is it possible and correct; that we could add some gracefulness when overwriting?

I know the *getNextOverwriteCandidate() is there for the same purpose, if explicitly called.

If I understood the code correctly, obviously there will be no way to retrieve the overwritten entry if the caller doesn't explicitly call the the method provided.

I get that it's up-to the caller to take care of that, as size and other sufficient methods are provided. But, "basically I thought is it possible to take care of that; implicitly in the add itself".

POC:

//... std::tuple<PushStatus, T*> add(const T &&el){ if (entries_.size() < maxSize_) { // Haven't reached max buffer size yet, just add and grow the buffer entries_.emplace_back(el); cursorEnd_++; numToConsume_++; return std::make_tuple(PushStatus::OK, nullptr); } else if (numToConsume_ == maxSize_) { // Drop the oldest (yet unconsumed) element in the buffer auto entryToBeOverwritten = entries_[position_]; entries_[position_] = el; cursorEnd_ = (cursorEnd_ + 1) % maxSize_; position_ = (position_ + 1) % maxSize_; cursorStart_ = position_; return std::make_tuple(PushStatus::DROP, &entryToBeOverwritten); } else { // Overwrite the oldest (but already consumed) element in the buffer auto entryToBeOverwritten = entries_[position_]; entries_[position_] = el; position_ = (position_ + 1) % entries_.size(); cursorEnd_ = position_; numToConsume_++; return std::make_tuple(PushStatus::OVERWRITE, &entryToBeOverwritten); } } //...

At caller's side:

//... PushStatus pushStatus; T* mayBeOverwrittenEntry; std::tie(pushStatus, mayBeOverwrittenEntry) = bcf.add(newElement); //...

This does not seem to have significant overhead, and I agree with that; it may affect DX :)

WDYT?

Thanks for the feedback!

Yes, it's a good suggestion.

I initially did it this way, in fact, but then decided against it, in order to keep the API simpler.

We only need to know which element we'll overwrite in some limited use cases (in particular, for the case of mark performance entries, which also additionally need a separate lookup-by-name registry).

So my idea was to kind of keep simple things simple, and complex ones possible, in this case :)

But your suggestion would definitely work great as well.

Yes, it's a good suggestion.

Thanks :)

I initially did it this way, in fact,

👍 This means I'm also on the right path of learning.

We only need to know which element we'll overwrite in some limited use cases (in particular, for the case of mark performance entries, which also additionally need a separate lookup-by-name registry).

Definitely. Btw, I wasn't aware of these specifics, thanks.

So my idea was to kind of keep simple things simple, and complex ones possible, in this case :)

For sure.

But your suggestion would definitely work great as well.

Again, thanks for validating my suggestions. I did learn something new here :)

facebook-github-bot · 2023-03-31T11:23:11Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 16e5ed095092672e972e718c1f763ac3a0cbdce2

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 4211adc38bef7e29bcdabd3298b4dd2033ad7cfd

facebook-github-bot · 2023-03-31T11:37:36Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 118e9284a6952558024b98b8d60c15c083b9e223

facebook-github-bot · 2023-03-31T11:41:36Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 391b93d29082a40878eefd128b395017545ab2d6

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 6b6aba0a176c720bfbaae326333c84414530a42b

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 12d3e7b8be4ebbc4a299681cd55434bac33e0934

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 8b9eb8d5a5f3f6c6793802777a0c1cb61823dab1

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: a48a7cbc3d749e771dac1973b3acdbe680210926

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: c5da8c7cbfe86d109b90fede5e86d5e0008ec9ce

facebook-github-bot · 2023-04-03T09:31:18Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten. {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: e88e600bbea0706e00b75dbe79f26aabe0eec0b0

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 67e8469005df5ea7dfe737d35eba9f76a187dd17

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 0365a3ed31a41e6de99659b103048d372842690b

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: a1f1d3468acb935bc4f9f75fef1c23d68f588ca9

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: ef61a23ed28cb5c1722e7d9f006555d8644faf9f

facebook-github-bot · 2023-04-03T09:37:59Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten. {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 62bab6f022813a6b5ee3f499217669dd40f84b8b

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 0f058aaf328d2d46eadd4883ddac07b4492091a2

facebook-github-bot · 2023-04-03T12:13:47Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten. {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: D44544057 fbshipit-source-id: 428c458305f75c59266aabf51f59061dc7f135c4

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 0085af03c64b4328dba58bae6dec9d77aaaed852

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: a0c1c0974760808d6ed1769dad9acf3f3f56eaa7

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten. {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Reviewed By: sammy-SC Differential Revision: D44544057 fbshipit-source-id: 9e5a0110da125b782892f404bb5867a3c32ba50d

facebook-github-bot · 2023-04-03T12:34:13Z

This pull request was exported from Phabricator. Differential Revision: D44544057

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Differential Revision: https://internalfb.com/D44544057 fbshipit-source-id: 913b10ec996e8ddf707c87a3fbb97345219c4271

facebook-github-bot · 2023-04-03T13:18:39Z

This pull request has been merged in 1387179.

…acebook#36726) Summary: Pull Request resolved: facebook#36726 ## Changelog: [Internal] - This implements (together with unit tests) a generic container type, `BoundedConsumableBuffer` with the following properties: * It can only grow up to a specified max size * It's a circular buffer (the oldest elements are dropped if reached max size and adding a new element) * The entries can be "consumed" (once), which from the point of view of the consumer effectively clears the buffer * Even after the entries are consumed, all of the non-overwritten entries can still be independently retrieved an arbitrary amount of times The buffer effectively wraps around when adding new elements. Once an element added, it becomes "consumable" (or "observable") and remains such, until all of the current outstanding elements are explicitly "consumed". It doesn't get immediately removed from the buffer, however (if max buffer size allows), and can be later retrieved via the `getEntries` API, until eventually overwritten. {F928241747} The goal is to use it for buffering performance entries in the native WebPerformance implementation, where the model is that the performance entries should be both buffered/observable, but also for certain performance entry types (such as marks, measures and potentially certain event types) should be possible to retrieve all of them at any time (regardless of whether they have already been observed or not). In fact, this container is factoring that behavior, which is already there in `PerformanceEntryObserver` (but in an ad-hoc manner and only applicable to marks/measures), with the goal of being able to do it for any performance entry type. Reviewed By: sammy-SC Differential Revision: D44544057 fbshipit-source-id: 5b7d055a6fc813ebb0fb30f9b346723161774260

facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Facebook Partner: Facebook Partner fb-exported labels Mar 30, 2023

rshest force-pushed the export-D44544057 branch from d37859a to 2c291c9 Compare March 30, 2023 16:57

rshest force-pushed the export-D44544057 branch from 2c291c9 to eff87e9 Compare March 30, 2023 20:19

rshest force-pushed the export-D44544057 branch from eff87e9 to 57c69f2 Compare March 30, 2023 21:37

rshest force-pushed the export-D44544057 branch from 57c69f2 to 4613761 Compare March 30, 2023 22:06

Pranav-yadav reviewed Mar 31, 2023

View reviewed changes

rshest force-pushed the export-D44544057 branch from 4613761 to 9d0ef97 Compare March 31, 2023 11:23

rshest force-pushed the export-D44544057 branch from 9d0ef97 to 9316922 Compare March 31, 2023 11:37

rshest force-pushed the export-D44544057 branch from 9316922 to 6d434c1 Compare March 31, 2023 11:41

rshest force-pushed the export-D44544057 branch from 6d434c1 to ae396c6 Compare April 3, 2023 09:31

rshest force-pushed the export-D44544057 branch from ae396c6 to 25e8001 Compare April 3, 2023 09:38

rshest force-pushed the export-D44544057 branch from 25e8001 to ecb262a Compare April 3, 2023 12:13

rshest force-pushed the export-D44544057 branch from ecb262a to ad2389b Compare April 3, 2023 12:34

facebook-github-bot closed this in 1387179 Apr 3, 2023

facebook-github-bot added the Merged This PR has been merged. label Apr 3, 2023

Implement specialized container type for performance entry buffering #36726

Implement specialized container type for performance entry buffering #36726

Uh oh!

Conversation

rshest commented Mar 30, 2023

Changelog:

Uh oh!

facebook-github-bot commented Mar 30, 2023

Uh oh!

facebook-github-bot commented Mar 30, 2023

Uh oh!

analysis-bot commented Mar 30, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

facebook-github-bot commented Mar 30, 2023

Uh oh!

facebook-github-bot commented Mar 30, 2023

Uh oh!

facebook-github-bot commented Mar 30, 2023

Uh oh!

Pranav-yadav Mar 31, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rshest Mar 31, 2023

Choose a reason for hiding this comment

Uh oh!

Pranav-yadav Mar 31, 2023

Choose a reason for hiding this comment

Uh oh!

facebook-github-bot commented Mar 31, 2023

Uh oh!

facebook-github-bot commented Mar 31, 2023

Uh oh!

facebook-github-bot commented Mar 31, 2023

Uh oh!

facebook-github-bot commented Apr 3, 2023

Uh oh!

facebook-github-bot commented Apr 3, 2023

Uh oh!

facebook-github-bot commented Apr 3, 2023

Uh oh!

facebook-github-bot commented Apr 3, 2023

Uh oh!

facebook-github-bot commented Apr 3, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

analysis-bot commented Mar 30, 2023 •

edited

Loading

Pranav-yadav Mar 31, 2023 •

edited

Loading