Closed Bug 1487457 Opened 7 years ago Closed 7 years ago

Make console reflows faster

Categories

(DevTools :: Console, enhancement, P1)

enhancement

Tracking

(firefox64 fixed)

RESOLVED FIXED
Firefox 64
Tracking Status
firefox64 --- fixed

People

(Reporter: nchevobbe, Assigned: nchevobbe)

References

Details

(Keywords: perf)

Attachments

(1 file)

In Bug 1486996, Brad mentioned that quite some time was spent in dealing with possible scrollbars during the console reflows. We should ensure that elements that we know won't ever overflow have a `overflow: hidden` rule.
Assignee: nobody → nchevobbe
Status: NEW → ASSIGNED
Priority: -- → P1
This patch remove some unused dom elements and CSS rules that might negatively influence reflow times. Also, we set an hidden overflow to all the element we know for sure won't ever have a scrollbar, which seems to speed up the reflow significantly.
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2) > See how the soon to be `typing` DAMP test reacts to this change (17% > improvement): > https://treeherder.mozilla.org/perf.html#/ > comparesubtest?originalProject=try&originalRevision=c300f4079d62165bb4cc91e3b > cf3b82abb4dcd06&newProject=try&newRevision=6aec83d3460acc5ea298f10adb75246b8f > 673df6&originalSignature=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&newSignatur > e=f79b6a4f1f8f53326d3056f6c8008c0ff4de0a94&filter=typing&framework=12 Wow, nice
Comment on attachment 9005254 [details] Bug 1487457 - Make console reflows faster; r=bgrins. Brian Grinstead [:bgrins] has approved the revision.
Attachment #9005254 - Flags: review+
This makes me think we might want a Devtools API to determine whether or not overflow: auto is "expensive". That would allow us to make conscious decisions of when we want to trade UI purity for performance -- by setting overflow: scroll or overflow: hidden when we know that auto would be a performance degradation.
(In reply to Brad Werth [:bradwerth] from comment #6) > This makes me think we might want a Devtools API to determine whether or not > overflow: auto is "expensive". That would allow us to make conscious > decisions of when we want to trade UI purity for performance -- by setting > overflow: scroll or overflow: hidden when we know that auto would be a > performance degradation. Not so much a conscious decision as a _runtime_ decision, in JavaScript. Not sure if that's helpful.
So, without the message overflow change, we have around 3.7% improvement (https://treeherder.mozilla.org/perf.html#/comparesubtest?originalProject=try&originalRevision=7d10a0ea891bb5e8c4e80e3084e459d85acdda82&newProject=try&newRevision=03dad18abf7526120d4009aef14d876a5e473c19&originalSignature=d0aa31b4a8617d5bda9bc8c5ca7bfa9a77c38c7c&newSignature=d0aa31b4a8617d5bda9bc8c5ca7bfa9a77c38c7c&showOnlyImportant=1&framework=12) Then when we only apply the overflow: hidden on `message`, it regresses by ~4% (https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=03dad18abf7526120d4009aef14d876a5e473c19&newProject=try&newRevision=51fc6d59da8799c002ebee26fcd7dd49eca90769&framework=12) When adding the `.message * {overflow: hidden}`, we get around 44% improvement on top of previous (https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=51fc6d59da8799c002ebee26fcd7dd49eca90769&newProject=try&newRevision=ce5e4ad20b2d04f3c1447707ce8c1ddd9b91490b&framework=12). When then removing the overflow: hidden in .message, we get the 4% back (https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=ce5e4ad20b2d04f3c1447707ce8c1ddd9b91490b&newProject=try&newRevision=1968ad7c6c24eedcf308b0d2d6ebd72c2481dad3&framework=12) Overall, we can get a 46% improvement (from current code to simplify + overflow hidden on .message children elements) : https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=7d10a0ea891bb5e8c4e80e3084e459d85acdda82&newProject=try&newRevision=1968ad7c6c24eedcf308b0d2d6ebd72c2481dad3&framework=12
And here's some manual profiling when moving the cursor one line up with an output containing 500 messages: without patch https://perfht.ml/2wH7i1S 96ms https://perfht.ml/2M29o2f 105ms https://perfht.ml/2M3t1a2 103ms https://perfht.ml/2M85kxy 97ms https://perfht.ml/2wPc7Gw 95ms -> ~99ms reflows with patch https://perfht.ml/2wKWnnV 62ms https://perfht.ml/2M2KVJT 50ms https://perfht.ml/2M2Z3Dg 53ms https://perfht.ml/2M3gKST 52ms https://perfht.ml/2wH6MRu 50ms -> ~54ms reflows = almost 50% improvement !
Keywords: perf
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Blocks: 1490027
No longer blocks: 1490027
Depends on: 1490027
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: