Closed Bug 1487457 Opened 6 years ago Closed 6 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 !
Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/66bc93855cfa
Make console reflows faster; r=bgrins.
Keywords: perf
https://hg.mozilla.org/mozilla-central/rev/66bc93855cfa
Status: ASSIGNED → RESOLVED
Closed: 6 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: