We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7f5e2351eead0563eae3f26e51f35a68d3de9d9e&tochange=4ca7df7a6ab5a8d1471a9c0517ea0cc71d6e161f

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

Regressions:

1% installer size windows2012-32 opt 62,522,899.08 -> 63,349,402.67
1% installer size windows2012-32 pgo 65,723,597.08 -> 66,542,566.42

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

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 jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Automated_Performance_Testing_and_Sheriffing/Build_Metrics

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

Bug 1475564 enables libaom on Win32 to allow to play AV1. Of course it makes the installer larger :) (note this reverted bug 1445683)

How do we resolve this given it is expected behaviour and to avoid backing out?

We don't?

I more meant this specific bug. Based on comment 3 it sounds like the replies given are sufficient to avoid the backout mentioned in comment 0. Will mark as invalid as this behaviour is expected -- please advise should there be a more desirable course.

When filing perf bugs, what we rather want is reach one of these 3 conclusions: fix/wontfix/backout. There are many reasons why perf regressions appear and each new ones is handled in a specific way.
We only do backouts when we don't receive feedback in less than 3 working days.

I'm readjusting the resolution, to properly filter through our tracking bugs.