1468689 - 0.61% installer size (osx-cross) regression on push 29f8277992e56f87bd0337df7af4b5a10fa357f6 (Wed Jun 13 2018)

Status: RESOLVED WONTFIX

(Firefox Build System :: Toolchains, defect)

Description

[Ionuț Goldan [:igoldan]]

We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=29f8277992e56f87bd0337df7af4b5a10fa357f6

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

Regressions:

  1%  installer size osx-cross opt      65,441,577.08 -> 65,840,784.08


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

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]]

This is a pretty big installer size regression. What fixes are you considering?

Comment 2

[Mike Hommey [:glandium]]

This unfortunately means clang 6 generates larger code than the previously used version of clang (I think it was 5 for those builds). Do we have performance results yet? Hopefully, this should be compensated with performance improvements.

Comment 3

[Ionuț Goldan [:igoldan]]

(In reply to Mike Hommey [:glandium] from comment #2)
> This unfortunately means clang 6 generates larger code than the previously
> used version of clang (I think it was 5 for those builds). Do we have
> performance results yet? Hopefully, this should be compensated with
> performance improvements.

I'm afraid no related improvements showed up.

Comment 4

[Ionuț Goldan [:igoldan]]

Perf baseline on OS X remained the same.

Comment 5

[Mike Hommey [:glandium]]

Comparing the XUL binary size between the build before bug 1467658 landed and when it landed, shows a difference of 651704 bytes in the file size, but a slightly smaller difference in actual code/data size: 479330 bytes. The ~200K difference is likely in symbol tables and other metadata, which would affect release less (afaik, we strip symbol tables on release).

I'm not sure what to do here.

Comment 6

[Ionuț Goldan [:igoldan]]

(In reply to Mike Hommey [:glandium] from comment #5)
> Comparing the XUL binary size between the build before bug 1467658 landed
> and when it landed, shows a difference of 651704 bytes in the file size, but
> a slightly smaller difference in actual code/data size: 479330 bytes. The
> ~200K difference is likely in symbol tables and other metadata, which would
> affect release less (afaik, we strip symbol tables on release).
> 
> I'm not sure what to do here.

:sledru Given the fact you have ownership for this perf test, we ask for your advice here: should we work on a fix or rather accept this regression?

Comment 7

[Sylvestre Ledru [:Sylvestre]]

To be clear, not perf but size :)

I think that, in the context of the switch to clang on Windows and Linux, the advantages of using a more recent clang are more important the size regressions. 
If we feel strongly about it, we could see which revision of clang upstream introduced the size regression. Maybe it is an upstream regression...

Comment 8

[Joel Maher ( :jmaher ) (UTC -8)]

this change is now seen on mozilla-beta.

I don't see any action to take here, possibly wontfix?

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Agreed.