1.01 - 1.6% raptor-tp6-facebook-firefox / raptor-tp6-facebook-firefox raptor-tp6-facebook-firefox-loadtime (linux64) regression on push 9097dc60840f93fe9ebb697574c82cf15745ff37 (Fri Feb 1 2019)
Categories
(Core :: Privacy: Anti-Tracking, defect, P2)
Tracking
()
People
(Reporter: igoldan, Unassigned)
References
Details
(Keywords: perf, regression)
Raptor has detected a Firefox performance regression from push:
As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
2% raptor-tp6-facebook-firefox raptor-tp6-facebook-firefox-loadtime linux64 opt 345.77 -> 351.29
1% raptor-tp6-facebook-firefox linux64 opt 337.92 -> 341.33
You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=19182
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 Raptor jobs in a pushlog format.
To learn more about the regressing test(s) or reproducing them, please see: https://wiki.mozilla.org/Performance_sheriffing/Raptor
*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***
Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Performance_sheriffing/Talos/RegressionBugsHandling
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 1•5 years ago
|
||
These are the Gecko profiles for raptor-tp6-facebook on Linux 64bit (OPT builds):
|
||
Comment 2•5 years ago
|
||
Andrea, can you explain this?
|
||
Updated•5 years ago
|
|
||
Comment 3•5 years ago
|
||
The only explanation I have is that, with the pref enabled, we had a corresponding performance improvement and now, disabling the 2 classifiers we go back to previous values.
Somehow, loading facebook, we detect some cryptomining (I don't think this is possible), or fingerprinting (maybe...) resources and we block them.
Would be nice to see the log with and without the 2 classifiers. I'll try locally next week.
|
|
Reporter | |
Comment 4•5 years ago
|
||
Andrea, have you managed to find something?
|
||
Comment 5•5 years ago
|
||
:ehsan this appears to have stalled, is there someone else that can help to investigate?
|
||
Updated•5 years ago
|
|
|
||
Comment 7•5 years ago
|
||
Disabling fingerprinting/cryptomining features would make Nightly to behave like beta/release. This means that nightly was faster with the 2 features enabled and, now it's equal to beta/release with the features disabled. This is kind of expected, because fingerpriting/cryptomining features blocks the loading of resources, and that could make the loading faster (sometimes this is not true and we have performance regressions).
So, I think there is nothing we should do here.
|
|
Reporter | |
Updated•5 years ago
|
Description
•