We have detected a build metrics regression from push: https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=a344042d76e92e824f153da614d6571d63a2c71b As author of one of the patches included in that push, we need your help to address this regression. Regressions: 3% build times summary linux32 pgo taskcluster-c4.4xlarge 2,940.39 -> 3,014.01 1% compiler warnings summary linux64 asan asan debug 380.92 -> 385.17 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=7135 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
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
We added a new 3rd-party library, so I'm not surprised by the build time increase. (But only on linux32 pgo?) Warnings we can fix.
Assignee: nobody → giles
Just saw an installer size alert show up for this revision: == Change summary for alert #7135 (as of June 08 2017 21:27 UTC) == Regressions: 3% build times summary linux32 pgo taskcluster-c4.4xlarge 2,940.39 -> 3,014.01 1% installer size summary linux32 opt 59,684,253.08 -> 60,392,248.42 1% compiler warnings summary linux64 asan asan debug 380.92 -> 385.17 For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=7135 Letting :sylvestre know so he can track this.
Can we build/ship only the part that we use in aom? (if it is not the case)
status-firefox53: --- → unaffected
status-firefox54: --- → unaffected
status-firefox55: --- → affected
We're currently using only the decoder, so I could try patching out the encoder until we need it for the WebRTC and MediaRecorder APIs. However, this is a nightly-only experiment; the regression should be resolved by the code turning off entirely when Firefox 55 goes to beta.
status-firefox55: affected → disabled
status-firefox56: --- → affected
status-firefox56: affected → fix-optional
This change is nightly-only so it shouldn't affect Firefox 56 or 57 once it goes to beta.
status-firefox56: fix-optional → disabled
status-firefox57: --- → fix-optional
Same story through Firefox 60; this is still nightly-only code.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.