We have detected a build metrics regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=7e14986df45a685861ac2e75499286f62d8c8f1a

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

Regressions:

100KBytes installer size linux32 pgo 69,987,301.83 -> 70,162,668.83
100KBytes installer size linux64 pgo 69,892,793.79 -> 69,995,403.83
80KBytes installer size osx-cross opt 76,708,771.75 -> 76,786,228.58

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

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

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Same as in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1512447#c5

The patch fixes a case in which the stack smashing protection wasn't activated for part of our code.

The regression is normal and expected due to extra overhead from a new security feature.

This seems to have also affected the our Speedometer benchmark baseline:

== Change summary for alert #19936 (as of Sat, 16 Mar 2019 03:09:05 GMT) ==

Regressions:

3% raptor-speedometer-geckoview android-hw-g5-7-0-arm7-api-16 opt 9.21 -> 8.91

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=19936

Hmm, the original alert was also a GeckoView speedometer regression: https://bugzilla.mozilla.org/show_bug.cgi?id=1512447#c0

Seems like the performance impact on Android is larger than elsewhere? Not clear why that is though. Snorp, any input? We could disable SSP on Android if this 4-5% total is too much.

That hurts, but IMHO the safety is worth it. Would be interested in knowing the root cause of the slowdown, though. Maybe there are some toolchain things we can tweak?

:snorp is there any work on your end to address this or are you looking for something from the build team?

(In reply to Kim Moir [:kmoir] ET from comment #5)

:snorp is there any work on your end to address this or are you looking for something from the build team?

Right now I think no work necessary, but maybe a followup bug to try to figure out the root cause for the regression would be good? Or we can just use this one.

:snorp Is there any progress on this?

Given this is a P4 maybe we should open a new bug to fix this regression and close this as WONTFIX

(In reply to Florin Strugariu [:Bebe] (needinfo me) from comment #7)

:snorp Is there any progress on this?

Given this is a P4 maybe we should open a new bug to fix this regression and close this as WONTFIX

I'm not working on it. New bug seems fine.