WebPerfWG call - June 23 2022

Participants

Dan Shappir, Mike Henniger, Noam Helfman, Chenzhong Wu, Patricija Cerkaite, Carine Bournez, Yoav Weiss, Nic Jansma, Ian Clelland, Amiya Gupta, Annie Sullivan, Sean Feng, Steven Bougon, Pat Meenan, Lucas Pardue, Yoav Moshe, Benjamin De Kosnik, Abil Paul, Marcel Duran

Admin

Nic: Next meeting is July 7th 1pm ET 10am PT
… Wanted to talk about the survey on meeting times and share the results

… 16 responses, wanted to see what folks thought of the alternating times
… half the people are content. Some prefer the earlier or later specifically.
… Some comments about preferring a fixed time slot
… Majority view seems happy, so working for most people
… Understand preferences but hard to accommodate everyone
… Open to feedback but for now planning to continue this cadence

Minutes

ResourceTiming: Consider to limit the max size of resource timing buffer

Summary

ResourceTiming issue was opened due to a performance degradation on a popular website that was logging 100k+ RT entries
We reviewed how all of the PerformanceEntrys have a different buffer behavior, and discussed the option of enforcing a "hard limit" maximum RT buffer size that could be requested, but came to the conclusion that one path would be just a spec change to note that implementers could choose to enforce a limit if they desired (and not having a spec'd limit). We decided to not make this change yet.
Since the main concern was around Chromium implementation having perf issues as the number of RT entries increased, Yoav was going to follow up by doing some research. Based on that research, implementation bugs may be filed (or spec changes would be considered).

Minutes

Nic: proposal to limit the maximal buffer size for resource timing
… set to 256 by default
… you can increase it. The only API where you manage the buffer
… Some sites chose to increase it to basically infinity
… Reports where this was causing slow down when fetching the data
… The proposal is to have a maximum cap, where a higher value would be limited to that cap
… Most of the discussion that happened on the bug. Wanted to see if there’s a preference
Ian: Limiting it is probably a good idea. But confused about people that use the performance APIs and then can’t find such slowdowns
Nic: Should this apply to other buffer sizes? There are no other APIs that developers can control the buffer size, and this also was a mistake, where we had issues with this shared resource creating conflicts between different parties
Ian: Should there be just a single master buffer? Should there be a limit to all the entries?
Nic: We have a registry with limits
… contains a list of max buffer sizes
… user timing is infinite
… Resource timing is 250
… Others are limited to 150, but only RT can be managed
… Makes sense to maintain a per entry maximum
Ian: second point, if sites are using perf APIs, they should have visibility into them slowing themselves down
Dan: Any API that you add can potentially slow your site down. You will have no insights into specific issues with the memory that would trigger here
… Maybe I’m being naive, but shocked that people would find it useful to create huge backlogs of perf entries. Doesn’t make sense
… Can think of e.g. ~1000, but beyond that it seems ludicrous
… Perf observer doesn’t save you given the buffer flag
… Struggling to think of where you’d need to retain all these entries in memory
… Maybe browsers can log to the console? Might be sufficient.
Amiya: for sanity, worth having a minimum value. E.g. you could imagine a 3P script setting the buffer to zero
Nic: Would still enable perf observer. A site may want to make sure the buffer is not taking memory. But managing the buffer can create conflicts with 3P scripts
Yoav: To me it seems like browsers could reasonably and cap the value, similar to having a recommended value for the browser size but browsers can override that with implementation-specific values
... Browsers could cap that max. Seems like a good place for intervention.
Nic: Nothing in the spec requires a specific max or min
Yoav: And we could in the spec say that browsers can override that with implementation specific values if they seem fit
Noam: wondering if it’s our role as part of this group to define such limits. If we can’t imagine a use case that doesn’t mean it doesn’t exist. Should we limit it?
… There’s no limit on how many DOM elements you add to the document and they can slow down your site as well
Sean: IIRC, the major perf issue was when calling getentriesByName which is sorted by the start time
… Was with a mix of resource timing and other entry types
… The sorting was causing performance issues
… That was the motivation for a buffer size
… Maybe we can avoid sorting
Yoav: I wonder if this is implementation specific
... Try to make implementations faster first, before specifying a hard limit
Sean: Not an urgent performance issue for us
Yoav: I'll take a stab at chromium side
Nic: Should we add a clause that UAs can limit?
Yoav: Not yet needed, from my perspective

https://github.com/w3c/user-timing/issues/92

Summary

The buffer's limitation is mostly a NodeJS use case, to avoid libraries from accumulating entries without clearing them for long lived server applications.
Namespaces may reduce the issue by making it easier for libraries to collect their entries
Node can consider adding some limitation to the buffer as an intervention on their user's behalf.

Minutes

Nic: similar issue around adding a buffer limit to user timing
… concern that someone can overfill the UT buffer
… In the past we tried to avoid going down the path of buffer management
… Clearing the buffer adds a lot of complexity
Dan: The main issue is that there’s no obvious value to put for the buffer size. Is 1000 OK, 100000 OK? How much memory per entry?
… If it’s set too large and that results in perf implications, how would I know about it
… Maybe different values in dev vs. production
… doesn’t seem like something that a web developer should know how to set
Nic: You can manage the buffer through `clearMarks` and `clearMeasures`, but not limit it
… wanted to see if there are changes in opinions, as this was discussed before
Chengzhong: The problem is around implementing UT in node. Users complaining that they are creating entries and the buffer can grow very large
… They may not know that the buffer is getting larger, so don’t know to clear the entries
… Can have 3P libraries that create the entries and the site is not aware of it
… Limiting the timeline can reduce people’s need to care
Nic: So there could be 3P libraries in node that are adding entries without intentionally clearing them and the main app doesn’t know and growing memory for days
… you would hope that the 3P manage their lifetimes, but they don’t do that
Chengzhong: they could use an observer to clear the entries, but they may not care about it
Nic: If the host application knows that this is an issue, it could monitor and clear the buffer, but not all applications know that they should do that.
Chengzhong: In node there’s no page refresh, so no one would clear it
Dan: I totally agree that it’s a source of memory leaks, but no different from any other memory leak that exists in a 3P. It could add an object to an array and get the same issue
Yoav: You also opened an issue around namespaces with a proposal for namespaces that can be cleared based on a namespace
... That would potentially be an easier way for 3P libraries to also clear their entries, and if they limit them to a certain namespace
... Or allow main application to manage that namespace for 3P libraries that are polluting buffer
... Otherwise I agree with Dan that a JS application that runs for a very long time, you need to manage its memories and UT entries are not different
... The only difference is that when you're firing an entry you're not
Nic: disconnect when developers add timing entries and don’t know that they need to worry about the side effects? Maybe better documentation around memory management?
… geared towards longer lived apps
Yoav: Is there a use case for user timing in node?
Chengzhong: we have a report indicating memory leaks. Enabling to observe related methods on the server.
Yoav: Are those 3P expecting to also collect those UT entries, or something else is?
... Or would it make sense for Node to just No-Op'ing the API if it's irrelevant
… Maybe for server side application profiling
Nic: for SSR
Chengzhong: we’re using perfobserver to collect those entries, and it can be very useful
… code can run in both client side and server side, so shared with browser
… Node is trying to provide API compat as much as possible
Nic: Would be reasonable for node to say that the buffer size of user timing is zero, and only allow perf observer. Otherwise, mark and measure would be a no-op
Chengzhong: Accessing the buffer is a typescript feature request. Their whole app is sync, and have no async tasks, so can’t access perfObserver
Nic: Different considerations here for Node than what we expose on the web
… Not sure that for the web we want to allow limiting the buffer size
… But understand the considerations for node apps
Marcel: From prior experience, the reason some folks want to increase the size is because they care about their entries. Notice a few patterns - increase the buffer, get what they wanted and leave a huge buffer
… Typically for SPA that are long lived. Better to use an observer for that case
Nic: And that’s for resource timing?
Marcel: yeah, but this would be similar.
Yoav: Maybe this could be another case where Node could have interventions that limit the buffer size to some reasonable value, a parameter that's configured by the person running the server. I don't think we should add APIs to the web to address this use case.
... Hopeful that namespaces which is useful for the web as well allows 3P to clean up for themselves
Chengzhong: Sounds like a good approach. They can go with each other separately
Nic: Summarize that into the issue. Thanks for the discussion and context!

Shadow-Realms

Summary

3 open PRs that were merged to include support for Shadow-Realms
Since Shadow-Realms have not been implemented by any browser yet, WebIDL tests are failing for all UAs
Proposal to temporary revert PRs until Shadow-Realms is implemented in at least one browser, at which point we will consider re-merging

Minutes

Performance-timeline#193
User timing#85
HRTime#130
Yoav: We have a few PRs that have landed or Shadow-Realms
... We've exposed them to window and worker, and these PRs expose those to Shadow Realms
... Shadow Realms enables to create a sub-realm that is not of typical window, which allows developers to have control, not touching window object and other things
... But they do want to have access to these APIs, HR timing, UserTiming, PerformanceTimeline, etc
... There were also PRs to add same exposure to ResourceTiming and ServerTiming, but those were closed as SRs don't have access to creating resources
... Makes sense to add exposure to SRs for those APIs
... At the same time, it doesn't seem like any implementation has done that or intends to in the near future
... As a result of the PR landing, and that there's automatic WPTs that come from SpecIDL, we not have tests failing for those implementations failing in all browsers
... From my perspective this is not great and I would prefer to revert those PRs until we have a clear path to implementation somewhere
... Any opinions?
Nic: Sounds good to me to keep those tests clean until we have an implementation that can actually pass them
Chengzhong: I'm one of the authors of Shadow Realms. Revert is just about the tests, the decision is not about exposing SRs?
Yoav: It seems fine to expose it, I would just like to revert the PRs until there's an implementation in Chromium, Firefox or Webkit.
... Did I properly characterize what Shadow Realms do?
... Are these web use-cases, or primarily Node?
Chengzhong: Still being discussed, not sure if we should expose HR time in SRs.
Nic: goal to revert temporarily, not a final decision
Yoav: Sounds like there was some contention on actually doing this as well
... We should revert them, and have a broader discussion before we land them
... I'll take an AI to revert