1364176 - 2.77 - 3.42% cart (windows8-64) regression on push 5aa7f8838b2bde66aec6bf7585861149940f4d50 (Tue May 9 2017)

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

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

Talos has detected a Firefox performance regression from push 5aa7f8838b2bde66aec6bf7585861149940f4d50. As author of one of the patches included in that push, we need your help to address this regression.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=656d4714e8031d95fdf4d57b997215c1ced3364f&tochange=5aa7f8838b2bde66aec6bf7585861149940f4d50

Regressions:

  3%  cart summary windows8-64 opt      27.80 -> 28.75
  3%  cart summary windows8-64 pgo      23.38 -> 24.03


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=6489

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: https://wiki.mozilla.org/Buildbot/Talos/Tests

For information on reproducing and debugging the regression, either on try or locally, see: https://wiki.mozilla.org/Buildbot/Talos/Running

*** 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: https://wiki.mozilla.org/Buildbot/Talos/RegressionBugsHandling

Comment 1

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

:lsalzman, this looks to be win8 specific cart regression, can you take a look at this and determine if there is anything we can do to reduce the regression, or if we should back it out or consider accepting the regression as is.

Comment 2

[Lee Salzman [:lsalzman]]

(In reply to Joel Maher ( :jmaher) from comment #1)
> :lsalzman, this looks to be win8 specific cart regression, can you take a
> look at this and determine if there is anything we can do to reduce the
> regression, or if we should back it out or consider accepting the regression
> as is.

In this case, the "optimization" that I had earlier introduced for gfxAlphaBoxBlur to use hardware acceleration is too dicey at small draw target sizes, because fixed hardware resource creation costs can outweigh the blur speedups on some drivers. I will accept the regression as is given it is small and hardware/driver dependent, since the alternative is even worse regressions by leaving the accelerated code without any triggering threshold.

Comment 3

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

thanks for making a decision quickly!