1852540 - maybeGet* calls for builtin protos in CacheIR.cpp can cause performance issues

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, task, P2)

Description

[Jan de Mooij [:jandem]]

There are a few places in CacheIR.cpp where we attach a stub only if the global already has a certain builtin prototype object. This can cause a performance cliff especially with eager baseline interpreter/jit use (where I noticed this when looking into a fuzz bug).

Fixing this improves the micro-benchmark below from 50 ms to 13 ms for me.

function g() {}
function f() {
    var t = new Date;
    var arr = [1, 2, 3];
    for (var i = 0; i < 10_00_000; i++) {
        if (i > 20) {
            g(...arr);
        }
    }
    print(new Date - t);
}
f();

Comment 1

[Jan de Mooij [:jandem]]

Attachment: Bug 1852540 - Fix some CacheIR generators to create objects if needed instead of failing to attach. r?iain!

This fixes a performance cliff in some cases where we'd attach a slower stub instead.
This could happen with spread calls for example.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/77cef1514d20
Fix some CacheIR generators to create objects if needed instead of failing to attach. r=iain

Comment 3

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/77cef1514d20

Comment 4

[Mayank Bansal]

This may have lead to a small improvement on AWFY-speedometer2-React-Redux-TodoMVC* tests : https://treeherder.mozilla.org/perfherder/graphs?highlightAlerts=1&highlightChangelogData=1&highlightCommonAlerts=0&selected=3912918,1754792126&series=mozilla-central,3735873,1,13&series=autoland,3912918,1,13&timerange=5184000&zoom=1694444285255,1694658645474,56.8046541887128,65.99355599102117

Comment 5

[Jan de Mooij [:jandem]]

Oh nice, thanks for checking. I wasn't expecting this to be a measurable win on SP3, but good to see it maybe showed up anyway :)