1806006 - 5.99 - 5.35% perf_reftest_singletons id-getter-5.html / perf_reftest_singletons id-getter-3.html + 3 more (Linux) regression on Tue December 13 2022

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Andrej (:aglavic)]

Perfherder has detected a talos performance regression from push 79c3e5d3415f70ad2b7babb2dba24f8b381cf254. 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)
6%	perf_reftest_singletons id-getter-5.html	linux1804-64-shippable-qr	e10s fission stylo webrender	585.96 -> 621.09
6%	perf_reftest_singletons id-getter-3.html	linux1804-64-shippable-qr	e10s fission stylo webrender	593.45 -> 628.24
6%	perf_reftest_singletons id-getter-6.html	linux1804-64-shippable-qr	e10s fission stylo webrender	586.46 -> 620.59
6%	perf_reftest_singletons id-getter-4.html	linux1804-64-shippable-qr	e10s fission stylo webrender	586.92 -> 620.60
5%	perf_reftest_singletons id-getter-3.html	linux1804-64-shippable-qr	e10s fission stylo webrender	588.22 -> 619.68

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 1804253

Comment 2

[Jan de Mooij [:jandem]]

I'm looking into this... It seems to be Linux-specific, I don't see this on the Mac/Windows graphs.

It's probably noise from changing certain checks in JIT code and C++ code. They should be more efficient (two loads less to check for native/proxy objects), but these micro-benchmarks are often sensitive to CPU cache or code layout changes.

Comment 3

[Jan de Mooij [:jandem]]

I bisected this on Try to part 4. I disassembled the GenericGetter function in the DOM bindings for a local browser build and our code is very similar to before but a few bytes shorter now. I suspect this is a cache or alignment thing that only affects the Linux machines.

I did notice a redundant null check with GetDOMClass. This is pre-existing but maybe I can use this bug to fix that...

Comment 4

[Jan de Mooij [:jandem]]

I did some more testing and the fix for the pre-existing issue in comment 3 is probably not worth it. I think we just have to accept this because our codegen is strictly better, it just perturbs these DOM micro-benchmarks somehow.