Open
Bug 962412
Opened 10 years ago
Updated 2 years ago
[meta] improve interruptibility of reflow
Categories
(Core :: Layout, enhancement)
Core
Layout
Tracking
()
NEW
People
(Reporter: jtd, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: meta, perf)
The latest telemetry data indicates that we have cases where reflow takes over half a second and in some cases even more than five seconds. Assuming most of these are interruptible, we should do a better job of interrupting these reflows to prevent chrome hangs. The latest telemetry stats for reflow timings: http://telemetry.mozilla.org/#nightly/29/HTML_FOREGROUND_REFLOW_MS_2 Reflow time in ms (range, count), 12/15 to 1/15 for Nightly 29: 785 1310 1,670,000 1310 2170 704,520 2170 3610 335,710 3610 6010 208,690 6010 10000 134,230 10000 inf 135,110 Total counts 71,060,000,000 While these are comparatively rare events, they would all be classified as "chrome hang" events. Based on a comment by bz, I put in a telemetry metric to measure how many very long reflows (currently defined as >5000ms) are interruptible: http://telemetry.mozilla.org/#nightly/29/LONG_REFLOW_INTERRUPTIBLE This is a "boolean histogram" where 0 means non-interruptible and 1 means interruptible. The data suggests that 74% of very long reflows are interruptible. I suspect some of these reflows are due to large text blocks, this is a known problem (see bug 934770). But it would be a good idea to try and come up with better metrics for determining the cause of long running reflows and then see what we can tweak to do a better job of interrupting reflows. One possible solution may be to tweak the parameters used for detecting when to interrupt reflow. As I understand it, we only interrupt when input events are pending and we only check for these every nth time a call to a ReflowFrame method is called. It might make sense to have an absolute timeout (i.e. even if no input events are waiting) and/or check for events more often (n = 200 currently). The logic for checking interrupts is in nsPresContext::CheckForInterrupt: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#2636
Reporter | ||
Comment 1•10 years ago
|
||
A number of chrome hangs have been labeled as "font" chrome hangs (see bug 859558) but many of these are better classified as "reflow hangs" in which text may or may not be a factor. Some of these may be long reflows due to things other than just text frames: https://bugzilla.mozilla.org/show_bug.cgi?id=859558#c5
Reporter | ||
Comment 2•10 years ago
|
||
Hmmm, given that improving interruptibility is really about preventing chrome hangs should this really be classified as an "enhancement"? Rather than a "nice to have" I think this is a "should have" but maybe there's a layout-specific criteria for bug vs. enhancement.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•