2.96 - 2.56% tp5n nonmain_normal_fileio / tp5n nonmain_normal_fileio (Windows) regression on Wed October 26 2022
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox106 | --- | unaffected |
| firefox107 | --- | unaffected |
| firefox108 | --- | wontfix |
| firefox109 | --- | wontfix |
People
(Reporter: aglavic, Unassigned)
References
(Regression)
Details
(4 keywords)
Perfherder has detected a talos performance regression from push 384adba1e38ced6494210b410584b0256f78aac6. As author of one of the patches included in that push, we need your help to address this regression.
Regressions:
| Ratio | Test | Platform | Options | Absolute values (old vs new) |
|---|---|---|---|---|
| 3% | tp5n nonmain_normal_fileio | windows10-64-2004-shippable-qr | e10s fission stylo webrender-sw | 464,335,749.83 -> 478,091,800.17 |
| 3% | tp5n nonmain_normal_fileio | windows10-64-2004-shippable-qr | e10s fission stylo webrender-sw | 463,347,579.75 -> 475,199,797.92 |
Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) may be backed out in accordance with our regression policy.
If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.
For more information on performance sheriffing please see our FAQ.
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1797019
Comment 2•3 years ago
|
||
Not sure how my patch impacted this/how to fix it.
As advised, I added a function in BrowserGlue.jsm _scheduleBestEffortUserIdleTasks (see https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/browser/components/BrowserGlue.jsm#2906,2960-2973), which, from what I understand, shouldn't cause such impact?
Mark, do you know if I misplaced my code or if there's something I can do (beside removing the probe altogether) to revert the performance impact?
Comment 3•3 years ago
|
||
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #2)
As advised, I added a function in BrowserGlue.jsm
_scheduleBestEffortUserIdleTasks(see https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/browser/components/BrowserGlue.jsm#2906,2960-2973), which, from what I understand, shouldn't cause such impact?Mark, do you know if I misplaced my code or if there's something I can do (beside removing the probe altogether) to revert the performance impact?
I think you've done the right thing, as there's other telemetry in that area.
I think the thing to understand is what is causing the significant amount of increased i/o? From your patch I doubt it is the telemetry part, so could it be the requestMIDIAccess call? If it is that, and there's no way to minimise it, then maybe we can't do much about it.
I think there is a way to get more information about what is causing the extra i/o but it doesn't appear to be documented. Redirecting the NI to a couple of people that might be able to help with this.
Updated•3 years ago
|
Comment 4•3 years ago
|
||
:nchevobbe, have you tried running the profiler on those tasks? You should be able to by clicking the "generate profile" button in treeherder. That should get you a bit more info.
Otherwise, I think removing a bit of code at a time to see which line is causing this would be the next step. I'm not able to find anything specific that can tell us where the extra io is coming from (apart from the profile maybe). The xperf test might also provide some insight, but it only measures startup from what I can tell so I'm not sure if it'll be too useful.
Updated•3 years ago
|
Comment 5•3 years ago
|
||
NI Nicolas to bring comment 4 into the attention radar.
Comment 6•3 years ago
|
||
(In reply to Greg Mierzwinski [:sparky] from comment #4)
:nchevobbe, have you tried running the profiler on those tasks? You should be able to by clicking the "generate profile" button in treeherder. That should get you a bit more info.
Sadly the triggered jobs keep failing (e.g. https://treeherder.mozilla.org/jobs?repo=autoland&fromchange=4bf6c23773ea84292963011072112dec90c22100&tochange=384adba1e38ced6494210b410584b0256f78aac6&selectedTaskRun=RVhTLk1-Qkm219hm4YMDuA.0)
I'll ask on matrix
Comment 7•3 years ago
|
||
checking back in. Can we do something about this for 108?
Comment 8•3 years ago
|
||
Set release status flags based on info from the regressing bug 1797019
Comment 9•3 years ago
|
||
Still not managed to get a profile from the task, giving this another shot in https://treeherder.mozilla.org/jobs?repo=try&revision=aac30c23b3dccd9428f4a81a0b820a948ea2a626
Updated•3 years ago
|
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Can't really see this in the graphs, resolve wfm.
Updated•3 years ago
|
Description
•