large DOM GC triggers during page load when reloading docs |
|||
Issue descriptionWhat steps will reproduce the problem? 1. Open docs.google.com and navigate to a specific document. 2. Wait for it to fully load. 3. Open devtools and go to the performance tab. 4. Start a performance profile, reload the page, and then stop the profile after the page is fully loaded. 5. Zoom into the start of the load just after the green vertical line on the profile What is the expected result? The browser should spending most of its time during load on network, parsing, and js for the new page. What happens instead? Often we will see a 30ms to 50ms DOM GC between starting to load the html document and when parsing can actually begin. The html document load is clearly being delayed by the extensive DOM GC. See the attached screenshot. (Note the devtools performance markers for DOM GC are not working in 69, so you must do this with 70+.) Would it be possible to: a. Delay DOM GC until after the load of the next page completes? I'm sure some devices will be under memory pressure and need an immediate GC, but on my test machine I had plenty of free memory. b. Limit how long DOM GC can run during page load? c. Optimize the DOM GC in the case where we are discarding an entire execution context? Given that we are completely replacing the page I wonder if its possible to do any kind of bulk deletion.
,
Oct 14
The only thing Oilpan is doing is to disable incremental marking during a loading phase (because throughput is more important than responsiveness during loading). We have not yet implemented any mechanism to suppress Oilpan GCs during loading, but as you mentioned, this is worth a try. I remember V8 is doing a similar thing. keishi@: Shall we lower the threshold of Oilpan GCs during loading and see how it goes in Finch?
,
Oct 15
Maybe another option would be to keep incremental mode enabled during load, but increase the size of the time slice each increment can take during load. That might still increase oilpan throughput, but provide some reasonable bound on how long the next load could be blocked.
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
|||
►
Sign in to add a comment |
|||
Comment 1 by kinuko@google.com
, Oct 12