Closed Bug 1798749 Opened 3 years ago Closed 3 years ago

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)

defect

Tracking

()

RESOLVED WORKSFORME
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.

Flags: needinfo?(nchevobbe)

Set release status flags based on info from the regressing bug 1797019

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?

Flags: needinfo?(nchevobbe) → needinfo?(standard8)

(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.

Flags: needinfo?(gmierz2)
Flags: needinfo?(dave.hunt)
Flags: needinfo?(standard8)

: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.

Flags: needinfo?(gmierz2)
Flags: needinfo?(dave.hunt)

NI Nicolas to bring comment 4 into the attention radar.

Flags: needinfo?(nchevobbe)

(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

Flags: needinfo?(nchevobbe)

checking back in. Can we do something about this for 108?

Flags: needinfo?(nchevobbe)

Set release status flags based on info from the regressing bug 1797019

Still not managed to get a profile from the task, giving this another shot in https://treeherder.mozilla.org/jobs?repo=try&revision=aac30c23b3dccd9428f4a81a0b820a948ea2a626

Flags: needinfo?(nchevobbe)
Severity: -- → S3

Can't really see this in the graphs, resolve wfm.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.