1412776 - 1.19% installer size (windows2012-32) regression on push 6fe3d70877ed801274cc2f0da5490a8d6474d285 (Fri Oct 27 2017)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Ionuț Goldan [:igoldan]]

We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=6fe3d70877ed801274cc2f0da5490a8d6474d285

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

Regressions:

  1%  installer size summary windows2012-32 pgo      56,455,330.42 -> 57,126,690.67

Improvements:

 11%  build times summary windows2012-32 pgo taskcluster-c4.4xlarge     5,146.91 -> 4,558.04
 11%  build times summary windows2012-64 pgo taskcluster-c4.4xlarge     5,579.37 -> 4,988.39


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

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

[Ionuț Goldan [:igoldan]]

:dmajor Updates to Windows build config caused this installer size regression. Can you take a look over this issue? Is there something we can do to resolve this or should we accept it?

Bug 1408789 gave some small Talos improvements, but also some regressions on Windows PGO builds. I will file a separate bug for the Talos regressions.

Comment 2

[(Away)]

There is a size increase in xul.dll that accounts for essentially all of the installer-size regression.

I looked at the delta with the "SymbolSort" tool, and it looks pretty normal for a compiler change. (No unexpected gotchas like accidentally turning on an ifdef or pulling in a huge tree of libraries.) I think we should accept this growth in exchange for the faster code.

A small good news is that while investigating this, I discovered bug 1412889, which is completely unrelated to the VS2017 change, but it has the potential to win back a large amount of code size.