1775009 - 4.67% assorted-dom (Windows) regression on Tue June 14 2022

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine: JIT, defect)

Description

[Alexandru Ionescu (needinfo me) [:alexandrui]]

Perfherder has detected a browsertime performance regression from push 747c5d43a388e5cd9b647f1150693cd9ba820c14. 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%	assorted-dom	windows10-64-shippable-qr	fission webrender	18.93 -> 19.82

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.

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 1773971

Comment 2

[Jan de Mooij [:jandem]]

Micro-benchmarks could be affected by pushing the frame pointer in the exit frame. It could also be an alignment thing. I want to see if bug 1774546 affects this, but this is likely WONTFIX.

Comment 4

[Jan de Mooij [:jandem]]

Looking at the graph, this improved again yesterday. It could be from bug bug 1774546 or an unrelated change.

The external-string-pass.html regression from bug 1775140 is still there. The graph looks a little bimodal: some data points are still faster, and it only happens on Win64 (Linux64 and macOS are unaffected). This is a micro-benchmark calling a DOM setter in a tight loop so I suspect that pushing the frame pointer just slightly changes stack alignment or CPU cache behavior on the Windows machines. I think we have to accept this regression.