1126314 - 3-11% Linux* tp5o_scroll/tresize/tscrollx-ASAP regression on Mozilla-Inbound-Non-PGO on January 26, 2015 from push 7c4059ebfcf7

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Vaibhav (:vaibhav1994)]

Talos has detected a Firefox performance regression from your commit 7c4059ebfcf7 in bug 1116588.  We need you to address this regression.

Details of the regression:

  This is a list of all known regressions and improvements related to your bug:
  http://alertmanager.allizom.org:8080/alerts.html?rev=7c4059ebfcf7&showAll=1

  On the page above you can see Talos 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, please see: https://wiki.mozilla.org/Buildbot/Talos/Tests#tresize

Reproducing and debugging the regression:

  If you would like to re-run this Talos test on a potential fix, use try with the following syntax:
  try: -b o -p linux -u none -t chromez

  * if you want to see sps profiling, please adjust your try syntax to be:
    try: -b o -p linux -u none -t chromez mozharness: --spsProfile

  To run the test locally and do a more in-depth investigation, first set up a local Talos environment:
  https://wiki.mozilla.org/Buildbot/Talos/Running#Running_locally_-_Source_Code

  Then run the following command from the directory where you set up Talos:
  talos --develop -e <path>/firefox -a tresize

Making a decision:

  As the patch author we need your feedback to help us handle this regression.

  Some options to consider:
    1) If you are planning to investigate and fix this regression, let us know a time frame. You can also just back out this patch now and do the investigation later.
    2) If it seems impossible that this regression is caused by your patch, let us know ASAP.
    3) If this regression is expected, and we should accept this regression, please explain why and we will close the bug.
    4) If the scope and scale of the regression does not justify the time & effort required for an investigation, let us know and we can close the bug.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

:kats, can you comment on the next course of action as noted above, we would like to have this moving along by Friday (Jan 30).

Comment 2

[Kartikaya Gupta (email:[e-mail])]

roc, would you consider these regressions acceptable from removing the opacity:0 optimization? Do you think they're representative of real-world scenarios? See also bug 1116588 comment 24 and 25 for some more regression numbers (which don't seem to be listed on the alertmanager link above).

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Mysterious.

There is some opacity:0 content in the Firefox UI, but not much. I wouldn't have thought it would cause this kind of impact.

I think probably we should revert this and go back to the approach you were trying before, keeping the opacity:0 optimization. I'll comment in the original bug.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

(In reply to Vaibhav (:vaibhav1994) from comment #0)
> Making a decision:
> 
>   As the patch author we need your feedback to help us handle this
> regression.

I'll take option 1 and investigate alternate approaches to fixing the original bug which don't incur such a performance regression. Assigning this bug to myself, and I'll do the work in this bug as per https://bugzilla.mozilla.org/show_bug.cgi?id=1116588#c28

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I ended up backing out bug 1116588 after all, to fix another regression that was filed. The backout:

https://hg.mozilla.org/integration/mozilla-inbound/rev/74f29dfebd9c

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Backout was merged.