1754751 - 5.17 - 2.78% tabswitch / tabswitch (Windows) regression on Thu February 3 2022

Status: RESOLVED WONTFIX

(Toolkit :: Performance Monitoring, defect)

Description

[Andrej (:aglavic)]

Perfherder has detected a talos performance regression from push b24313d474bbb652baaf805a622add67cf8c2a76. 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)
5%	tabswitch	windows10-64-shippable-qr	e10s fission stylo webrender-sw	7.20 -> 7.57
3%	tabswitch	windows10-64-shippable-qr	e10s fission stylo webrender-sw	7.36 -> 7.56

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) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Comment 1

[Florian Quèze [:florian]]

It makes sense that the patch from bug 1747138 affects these numbers a little bit, as it adds collection of CPU time whenever a process priority changes, and when doing a tab switch the content process priority changes from BACKGROUND to FOREGROUND.

I'm surprised this isn't in the noise level of the test, but the value is now up to 0.37ms more than before, that's not a massive change.

I suspect most real users won't be in the situation that the test is measuring (calling gBrowser.selectedTab = tab) because when moving the mouse over a tab, we warm the tab, and that changes the content process' priority to FOREGROUND.

So the small regression might only affect users that don't hover the tab before switching to it. I would guess that might be users switching tab through keyboard shortcuts (other than ctrl+tab that warms the tabs), and maybe users using touch screens.

Mike, does the above seem reasonable, and if so do you agree that I should WONTFIX this bug?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to Florian Quèze [:florian] from comment #1)

Mike, does the above seem reasonable, and if so do you agree that I should WONTFIX this bug?

It does. If we're in agreement that we want to capture this data (which it sounds like we do), and we're willing to pay a small known overhead cost to get it (which it sounds like we are), then this seems like a fine regression to take. Plus, the tabswitch test renders in ASAP mode, so what we're seeing is a slight increase in average time it takes to draw the frames when doing the tab switch, but we're still well under the 16ms budget.

Comment 4

[Florian Quèze [:florian]]

Thanks Mike!

WONTFIX per comments 1 and 3.