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
: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.
Component: Untriaged → Graphics
Product: Firefox → Core
(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.
thanks for making a decision quickly!
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.