1894723 - Retaining display lists slows down speedometer3 significantly

Status: NEW

(Core :: Web Painting, enhancement)

Description

[Olli Pettay [:smaug][[e-mail]]]

layout.display-list.retain = false
https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=a0d7ecb6502670daf9cfa304becf7a56f89e712a&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=c95ecf9b476770104de2e88e5dc211465c861947&page=1&showOnlyConfident=1&replicates=1

Comment 1

[Timothy Nikkel (:tnikkel)]

I guess generally speaking the types of paints we see during a run of speedometer3 aren't the types of paints where we expect retained display lists to be a win in general. The paints tend to change a lot of things on the page from my impression, whereas retained display lists tends to shine when we are changing a few things.

I did a few try pushes to explore this a little bit.

This is m-c vs retained display lists disabled, replicated smaug's link above, I did this to validate that I was doing the comparison correctly.

https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=8bf3525829e1769583637007788d61ff2eb56f74&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=15e317fb27a9531706076892063970bf2ec815ec&page=1&showOnlyConfident=1&replicates=1

This is disabling retained display list in chrome only vs mc, no perf change on sp3 it seems.

https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=db80c74bb6319345e26e36a095f979cc16afa10d&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=15e317fb27a9531706076892063970bf2ec815ec&page=1&showOnlyConfident=1&replicates=1

This is so called "retain.sc" mode which simplifies a lot of retained display list merging code by caching and invalidating display lists at the stacking context level. This compares retain.sc vs plain m-c. This seems to be a nice win. This project was mostly complete but didn't quite get pushed over the finish line.

https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=a5f7f434b62ad27f97921b044a0c63cee70e2615&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=15e317fb27a9531706076892063970bf2ec815ec&page=1&showOnlyConfident=1&replicates=1

This bumps the rebuild limit (the number of modified frames before we bail out of an incremental retained display list update and do a full rebuild) down to 100 from 500. This seems to be a nice win as well. I'm not sure how this limit was choosen, we'd want to look into why it was choosen as well as compare on some other testcases before changing it.

https://treeherder.mozilla.org/perfherder/comparesubtest?originalProject=try&newProject=try&newRevision=eab53a8df5b544885afaeb989d940c857ac32934&originalSignature=4586009&newSignature=4586009&framework=13&application=firefox&originalRevision=15e317fb27a9531706076892063970bf2ec815ec&page=1&showOnlyConfident=1&replicates=1

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

The limit 500 was added in https://bugzilla.mozilla.org/show_bug.cgi?id=1411248#c1
Looks like not too comprehensive testing.

I wonder if the limit could be a bit more dynamic - like if we learn that the incremental retained list update fails often for a site, we could lower the limit, and also if it succeeds always, then increase it until it starts to fail.

Comment 3

[Timothy Nikkel (:tnikkel)]

Do you mean the retained list update fails or the retained list update is slower then a full rebuild?

I don't have data but I would think that we aren't failing retained list updates repeatedly in common cases.