We have detected a build metrics regression from push: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=e83c311e5293902be4db4ecea17cff87c633f7cf As author of one of the patches included in that push, we need your help to address this regression. Regressions: >250KBytes installer size linux64 pgo 67,172,739.67 -> 67,446,806.50 >250KBytes installer size osx-cross opt 73,979,899.83 -> 74,273,593.25 ~250KBytes installer size linux32 pgo 67,010,578.42 -> 67,264,582.42 ~200KBytes installer size windows2012-64 pgo 67,833,667.92 -> 68,066,666.58 ~200KBytes installer size windows2012-32 pgo 64,801,324.75 -> 65,006,079.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=17436 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

More or less expected, we've landed a bit update to the biggest component in Firefox.

This was discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1376873#c107. Once the code coverage updates, we can have another look and see if there are more things that can be removed.

(In reply to Dan Minor [:dminor] from comment #2) > This was discussed here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1376873#c107. Once the code > coverage updates, we can have another look and see if there are more things > that can be removed. Could you let me know when that happens or point me to a bug I can check for when the code coverage updates?

It looks like it is up to date now.

Are there other things we can remove here so we reduce the installer size?

I will definitely look into this, but given it's P3 and a wontfix for firefox65, it's not my highest priority at the moment. Removing code we don't use from our webrtc.org build creates a maintenance burden for us. Upstream has said they don't want any more complexity in their build system because of the fact that we don't build half of their library. That means that any work we do to the build system here would have to be maintained as a separate patch against upstream by us. As a Q4 goal, we're trying to remove the number of separate patches we maintain against upstream in Bug 864513 so the last thing I want to do at the moment is to create more differences from upstream. Removing files from the build should improve our installer size. If we want to improve our code coverage, I'm guessing we would have to remove files from the repository as well. It's relatively easy to do so at the top level directory level, but once we get into sub-directories and individual files this would substantially increase the number of patches we maintain against upstream and cause a lot of conflicts during a merge when files get moved or renamed. I'll definitely have a look at this and see if there are some easy wins here, but I don't want to make future imports from upstream webrtc.org even more painful. The last one took me over 9 months.