User timing buffer size

[legendecas]

While investigating the use cases of https://github.com/w3c/user-timing/issues/86, I found that in cases like using a third-party library, the library can unconditionally create entries, and the user may not be aware of this behavior, and the global user-timing buffer may be overflown. In those cases, we may need another tool to improve the memory management of user timing APIs.

I'm thinking that a global limit on the user-timing buffer size, Performance.setUserTimingBufferSize, can help in the condition that users are not proactively clearing the entries and prevent the buffer to grow oversize, just like Performance.setResourceTimingBufferSize. When the buffer size grows over the limit, people can still observe the entries with the PerformanceObserver.

This addition is not overlapping with https://github.com/w3c/user-timing/issues/86. The buffer size limit could help in conditions when the measure producer (like third-party libraries) is not observing the measurements and thus not clearing the entries proactively. While #86 is for end-users who are producing entries and clearing the entries by themselves.

[yoavweiss]

We discussed this at the WebPerfWG call yesterday. It seems like the buffer's limitation is mostly a NodeJS use case, to avoid libraries from accumulating entries without clearing them for long lived server applications.

The conclusion was that namespaces may reduce the issue by making it easier for libraries to collect their entries, and that Node can consider adding some limitation to the buffer as an intervention on their user's behalf.

[legendecas]

Thank you for the suggestions! I believe an implementation-defined limit to the buffer size can be a good approach to the problem.