1801330 - 68.91 - 26.5% a11yr dhtml.html / a11yr dhtml.html + 4 more (Linux, OSX, Windows) regression on Mon November 14 2022

Status: RESOLVED WONTFIX

(Core :: Disability Access APIs, defect)

Description

[Andrej (:aglavic)]

Perfherder has detected a talos performance regression from push 0c66c3cc26c0fd5b8f3d59060d6c1ad3317cf2fd. 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)
69%	a11yr dhtml.html	windows10-64-shippable-qr	e10s fission stylo webrender	632.70 -> 1,068.71
69%	a11yr dhtml.html	windows10-64-shippable-qr	e10s fission stylo webrender-sw	632.76 -> 1,067.09
45%	a11yr dhtml.html	macosx1015-64-shippable-qr	e10s fission stylo webrender-sw	643.04 -> 932.34
32%	a11yr dhtml.html	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	771.02 -> 1,018.15
31%	a11yr dhtml.html	linux1804-64-shippable-qr	e10s fission stylo webrender	783.68 -> 1,028.64
27%	a11yr dhtml.html	linux1804-64-shippable-qr	e10s fission stylo webrender-sw	802.29 -> 1,014.86

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

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

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

Comment 2

[James Teh [:Jamie] (away returning 28 Jan)]

A performance regression in these tests is expected as a result of enabling Cache the World, our accessibility engine re-architecture. Caching content a11y trees trades a little more time spent in the content process (gathering cache data and pushing it) for spending a great deal less time in the parent process (making sync IPC calls for every a11y query). Unresponsiveness in the parent process is a lot worse for the user. Obviously, we want to reduce the time spent in the content process as much as we can, but we believe the gains outweigh the losses in this case (and external feedback suggests the same).

:andrej, can we establish a new baseline for these tests going forward? How do we go about doing that?

Comment 3

[Andrej (:aglavic)]

Hi James, if this is the new baseline due to enabling Cache the World I can set this as the new baseline thanks!