Closed Bug 1507714 Opened Last year Closed Last year

1.8% displaylist_mutate (linux64) regression on push a10cbfd5f4110f2e5f96095408aebd1f8acd1b87 (Thu Nov 15 2018)


(Core :: Layout, defect)

Not set



Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 --- fixed


(Reporter: igoldan, Assigned: jesup)


(Blocks 1 open bug)


(Keywords: perf, regression, talos-regression)


(1 file)

Talos has detected a Firefox performance regression from push:

As author of one of the patches included in that push, we need your help to address this regression.


  2%  displaylist_mutate linux64 opt e10s stylo     1,834.93 -> 1,867.94

You can find links to graphs and comparison views for each of the above tests at:

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see:

For information on reproducing and debugging the regression, either on try or locally, see:

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:
Component: General → Layout
Product: Testing → Core
Flags: needinfo?(rjesup)
(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #1)
> Here are the Gecko profiles for displaylist_mutate on Linux 64bit OPT builds:

PGO builds on Linux have been similarly influenced as well.
Not surprising, if we haven't had a contentful paint.  Normally in a real page I wouldn't expect much to happen displaylist-wise before we get a contentful paint - if so we can probably modify the test to paint first.  Alternatively (and if we think it's realistic in any real pages) we can investigate if we want to limit it or throttle the checks.
Flags: needinfo?(rjesup) → needinfo?(matt.woodrow) shows it is getting hit a little
Alternatively, and much more complexly, we could have ContentfulPaint (and any other similar items, though we should remove NonBlankPaint now I think) vampire off of earlier DisplayList work - maintain some sort of "DisplayList has contentful Paint" flag (perhaps a flag byte/etc for handling different "DisplayList has").
Try: - linux64-opt is done; shows no regression or perhaps even small gain (though likely that's illusory)
Attachment #9026198 - Flags: review?(matt.woodrow)
Assignee: nobody → rjesup
Attachment #9026198 - Flags: review?(matt.woodrow) → review+
Pushed by
ensure we get a contentful paint before a long-running test r=mattwoodrow
Pushed by
ensure we get a contentful paint before a long-running test r=mattwoodrow
Cleaned up ESLint warnings
Flags: needinfo?(rjesup)
I confirmed this bug got fixed:

== Change summary for alert #17698 (as of Tue, 20 Nov 2018 07:47:06 GMT) ==


  4%  displaylist_mutate osx-10-10 opt e10s stylo     4,963.13 -> 4,781.53
  2%  displaylist_mutate linux64 pgo e10s stylo       1,764.09 -> 1,726.27
  2%  displaylist_mutate linux64 opt e10s stylo       1,870.87 -> 1,838.01

For up to date results, see:
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: needinfo?(matt.woodrow)
You need to log in before you can comment on or make changes to this bug.