1506043 - 0.32 - 0.41% installer size (linux32, linux64, osx-cross, windows2012-32, windows2012-64) regression on push e83c311e5293902be4db4ecea17cff87c633f7cf (Thu Nov 8 2018)

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect, P3)

Description

[Ionuț Goldan [:igoldan]]

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

Comment 1

[Paul Adenot (:padenot)]

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

Comment 2

[Dan Minor [:dminor]]

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.

Comment 3

[Ionuț Goldan [:igoldan]]

(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?

Comment 4

[Dan Minor [:dminor]]

It looks like it is up to date now.

Comment 5

[Ionuț Goldan [:igoldan]]

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

Comment 6

[Dan Minor [:dminor]]

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.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Should we just wontfix this?

Comment 8

[Dan Minor [:dminor]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #7)

Should we just wontfix this?

I think so. With the way we're currently integrating gn, modifying the webrtc.org build is very time consuming and error prone, especially if we want to avoid breaking platforms we don't maintain directly.