2.07 - 2.78% compiler_metrics num_static_constructors (windows2012-32, windows2012-64, windows2012-aarch64) regression on push 88ed3923442a5527d87df3a05e31c7732239b953 (Thu September 26 2019)
Categories
(Firefox Build System :: Toolchains, defect)
Tracking
(firefox71 wontfix)
Tracking | Status | |
---|---|---|
firefox71 | --- | wontfix |
People
(Reporter: marauder, Unassigned)
References
(Regression)
Details
(Keywords: perf-alert, regression)
We have detected a build metrics regression from push:
As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
3% compiler_metrics num_static_constructors windows2012-32 debug 144.00 -> 148.00
2% compiler_metrics num_static_constructors windows2012-64 debug 144.00 -> 147.00
2% compiler_metrics num_static_constructors windows2012-64 debug fuzzing 145.00 -> 148.00
2% compiler_metrics num_static_constructors windows2012-aarch64 debug aarch64 145.00 -> 148.00
You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=23225
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! ***
Reporter | ||
Comment 1•5 years ago
|
||
The regression first occured in mozilla-inbound, then merged into mozilla-central and then in autoland:
de0fe40466cb3 -> 15ffd69c83be7 -> 88ed3923442a5
Did we not see any regression on opt or pgo builds? If this is only debug, then (even though I am curious) there is no perf implication and it's not worthwhile to investigate.
Reporter | ||
Comment 3•5 years ago
•
|
||
[Update]: the alert has been created on opt build.
The graph is similar for opt builds, but perfherder did not create an alert:
https://treeherder.mozilla.org/perf.html#/graphs?timerange=1209600&series=autoland,1844667,1,2&series=autoland,1844698,1,2&series=autoland,1920975,1,2&highlightAlerts=1&zoom=1569431961456,1569442729183,102.40712203022207,151.18339855703138
Should this alert be closed as won't fix or is a candidate for further investigations ?
Ah, ok, opt builds are more interesting. It looks like we only gained +2 there.
I will take a look. (But I think it's ok if this takes more than 3 days, there are other regressions that I need to investigate first)
Reporter | ||
Comment 5•5 years ago
|
||
"But I think it's ok if this takes more than 3 days, there are other regressions that I need to investigate first"
That's fine, no problem.
Thanks!
In opt we gained constructors for
FUNC 12ec300 41 0 static void mozilla::dom::RequestManager<mozilla::dom::StatsRequest,nsMainThreadPtrHandle<mozilla::dom::WebrtcGlobalStatisticsCallback>,mozilla::dom::WebrtcGlobalStatisticsReport,nsTSubstring<char16_t> >::`dynamic initializer for 'sRequests'()
FUNC 12ec380 41 0 static void mozilla::dom::RequestManager<mozilla::dom::LogRequest,nsMainThreadPtrHandle<mozilla::dom::WebrtcGlobalLoggingCallback>,mozilla::dom::Sequence<nsTString<char16_t> >,const nsTSubstring<char> >::`dynamic initializer for 'sRequests'()
They seem to be doing a malloc of 120 bytes each (on 64-bit) in their initializers. I'll keep looking...
These are false positives. The "new" constructors were still present before the patch landed, but clang had misreported their names in such a way that the constructor counting code didn't count them before.
For example, this name is reported properly in clang 9:
xul!mozilla::dom::RequestManager<...>::`dynamic initializer for 'sRequests'
Where clang 8 had previously reported the same code as:
xul!mozilla::dom::WebrtcGlobalChild::WebrtcGlobalChild+0x31
Updated•5 years ago
|
Updated•3 years ago
|
Description
•