Raptor has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c14813709eeb86deecd4725679e022e4478860d8&tochange=16ad89a4e4250059c7082f05487b60ccb0c53469

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

8% raptor-assorted-dom-firefox linux64-qr opt 24.15 -> 26.10
8% raptor-assorted-dom-firefox linux64 pgo 24.92 -> 26.80
6% raptor-assorted-dom-firefox linux64 opt 24.48 -> 26.07

You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=19383

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a Treeherder page showing the Raptor jobs in a pushlog format.

To learn more about the regressing test(s) or reproducing them, please see: https://wiki.mozilla.org/Performance_sheriffing/Raptor

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Performance_sheriffing/Talos/RegressionBugsHandling

These are the Gecko profiles for raptor-assorted-dom on Linux 64bit (OPT builds):

before: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FEWbO3sOpQhaQz_4G8f4DNw%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_raptor-assorted-dom-firefox.zip

after: https://perf-html.io/from-url/https%3A%2F%2Fqueue.taskcluster.net%2Fv1%2Ftask%2FIKgTR7wIQkW5Jxc2tCyvPw%2Fruns%2F0%2Fartifacts%2Fpublic%2Ftest_info%2Fprofile_raptor-assorted-dom-firefox.zip

I suspect this is the same issue we had recently: assorted-dom appears to be bimodal, sometimes it regresses for no apparent reason and then later it goes back to normal again.

(In reply to Jan de Mooij [:jandem] (PTO Fri 22 and Mon 25) from comment #2)

I suspect this is the same issue we had recently: assorted-dom appears to be bimodal, sometimes it regresses for no apparent reason and then later it goes back to normal again.

How certain are you about this? I looked over the graphs (from Linux PGO builds), but they don't seem to have returned to normal.

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #3)

I suspect this is the same issue we had recently: assorted-dom appears to be bimodal, sometimes it regresses for no apparent reason and then later it goes back to normal again.

How certain are you about this? I looked over the graphs (from Linux PGO builds), but they don't seem to have returned to normal.

Very certain. I investigated this more and I think we should WONTFIX/INVALID this because:

(1) Bug 1527843 should only affect things involving |new| or cross-realm functions and these tests don't have anything like that. It's just plain getters that are inlined and optimized to the point that we have an (almost?) empty loop (it's very sensitive to random code/cache changes).

(2) When this landed cross-realm functions weren't enabled for content code.

(3) We've seen very similar assorted-dom regressions and improvements lately. I was wondering about OPT and PGO both regressing, but that happened also in bug 1524482 for example.

Also note that the worker-getname-performance-getter subtest regressed by 18.33% on the "opt" build according to comment 0. In bug 1524482, which turned out to be a temporary regression/fluke, we had an 18.48% regression so it's the same order of magnitude as well.