You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: packages/utils/src/lib/performance-observer.ts
+5-41Lines changed: 5 additions & 41 deletions
Original file line number
Diff line number
Diff line change
@@ -97,14 +97,8 @@ export type PerformanceObserverOptions<T> = {
97
97
* Whether to enable buffered observation mode.
98
98
*
99
99
* When true, captures all performance marks and measures that exist in the Node.js
100
-
* performance buffer at the time `subscribe()` is called. This allows you to capture
101
-
* performance entries that were created before the observer was created.
102
-
*
103
-
* When false, only captures entries created after `subscribe()` is called.
104
-
*
105
-
* **Important:** The implementation uses a manual approach via `performance.getEntriesByType()`
106
-
* rather than the native PerformanceObserver `buffered` option. See the `subscribe()` method
107
-
* documentation for details on guarantees and limitations.
100
+
* performance buffer at the time `subscribe()` is called using `performance.getEntriesByType()`
101
+
* (the native `buffered` option is unreliable in Node.js).
108
102
*
109
103
* @default true
110
104
*/
@@ -317,37 +311,8 @@ export class PerformanceObserverSink<T> {
317
311
*
318
312
* Creates a Node.js PerformanceObserver that monitors 'mark' and 'measure' entries.
319
313
* The observer uses a bounded queue with proactive flushing to manage memory usage.
320
-
* When buffered mode is enabled, any existing buffered entries are immediately flushed.
314
+
* When buffered mode is enabled, existing entries are captured via `performance.getEntriesByType()` instead of the unreliable native `buffered` option.
321
315
* If the sink is closed, items stay in the queue until reopened.
322
-
*
323
-
* ## Buffered Mode Implementation
324
-
*
325
-
* When `captureBufferedEntries` is true, this method captures all performance entries
326
-
* that exist in the Node.js performance buffer at the time of subscription.
327
-
*
328
-
* **Why Manual Approach:**
329
-
* The standard `buffered: true` option in PerformanceObserver.observe() is not used
330
-
* because it has proven unreliable in Node.js environments. Instead, we use
331
-
* `performance.getEntriesByType()` to manually retrieve buffered entries.
332
-
*
333
-
* **Guarantees:**
334
-
* - All marks and measures in the performance buffer at subscription time will be captured
335
-
* - Entries are processed synchronously before the observer begins watching for new entries
336
-
* - No entries created after subscription will be missed (observer handles them)
337
-
*
338
-
* **Limitations:**
339
-
* - Potential for duplicate processing if an entry exists both in the buffer and is
340
-
* delivered by the observer callback (though Node.js typically avoids this)
341
-
* - Performance buffer has a limited size; very old entries may have been evicted by Node.js
342
-
* - The manual approach captures a snapshot at subscription time; there's a small race
343
-
* condition window where entries created during getEntriesByType() execution might
344
-
* be captured by both the manual call and the observer
345
-
*
346
-
* **Memory Management:**
347
-
* Applications should call `performance.clearMarks()` and `performance.clearMeasures()`
348
-
* periodically to prevent the Node.js performance buffer from growing unbounded.
349
-
* This is especially important when using buffered mode, as the entire buffer is
350
-
* processed on subscription.
351
316
*/
352
317
subscribe(): void{
353
318
if(this.#observer){
@@ -358,8 +323,7 @@ export class PerformanceObserverSink<T> {
0 commit comments