This 2% regression has gradually increased since January 10 2018. It affects Linxu 32 DEBUG builds. Bellow are the small regressions which got in, linked to their respective bugs. Only if you have the time, please consider fixing it, to lessen the overall regression. I understand this is lower priority. 0.5% (from 232 to 233) -> Bug 1429174, Jan 10, more here https://treeherder.mozilla.org/perf.html#/alerts?id=11247 0.5% (from 233 to 234) -> Bug 1427344 , Jan 12 more here https://treeherder.mozilla.org/perf.html#/alerts?id=11248 1% (from 234 to 236) -> Bug 1412726, Jan 12, more here https://treeherder.mozilla.org/perf.html#/alerts?id=11249 1% (from 236 to 237) -> Bug 1430312, Jan 13, more here https://treeherder.mozilla.org/perf.html#/alerts?id=11250

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #0) > 1% (from 236 to 237) -> Bug 1430312, Jan 13, more here > https://treeherder.mozilla.org/perf.html#/alerts?id=11250 You can ignore this one ^^^ This was us adding a StaticRefPtr -- and according to our documentation, StaticRefPtr is specially written so that it won't produce a static initializer **in release builds**: https://dxr.mozilla.org/mozilla-central/rev/5faab9e619901b1513fd4ca137747231be550def/xpcom/base/StaticPtr.h#21-22 Apparently it does produce one in debug builds, but that's not a problem because our users don't run debug builds. :)

I came here to say the same thing as dholbert. This is the expected behavior in debug builds.

FWIW, the one from bug 1427344 also affects opt builds, but is kind of a false regression. In the build before the landing, the .init section contained: 0000000000964068 <_init>: 964068: 48 83 ec 08 sub $0x8,%rsp 96406c: e8 f7 63 02 00 callq 98a468 <call_gmon_start> 964071: e8 1a 65 02 00 callq 98a590 <frame_dummy> 964076: e8 45 2f 19 04 callq 4af6fc0 <__do_global_ctors_aux> 96407b: 48 83 c4 08 add $0x8,%rsp 96407f: c3 retq The last function iterating the constructors in the .ctors section, which, practically speaking, was empty. The constructors were all already in the .init_array section. That's what we look at for the num_static_constructors count. In the build for the landing, the same section looks like: 0000000000964098 <_init>: 964098: 48 83 ec 08 sub $0x8,%rsp 96409c: e8 f7 63 02 00 callq 98a498 <call_gmon_start> 9640a1: 48 83 c4 08 add $0x8,%rsp 9640a5: c3 retq The .ctors section was removed, so there is no call to __do_global_ctors_aux, and the frame_dummy call also disappeared, but it moved to the .init_array section. So yes, we now count one more initializer because what used to be called from .init is not called through .init_array.