Go to https://www.complexity-explorables.org/explorables/eigenartig/
Click on the play button

ER: As fast as Chrome
AR: Slower

https://share.firefox.dev/3UYhMDE

I can visually reproduce this issue locally.
Profiling with Chromium, the c function takes 4.5% of the profile, while in Firefox the same c function takes 15%.
There is potentially some other offenders such as Object.assign, but I cannot find any equivalent in Chromium profiles.

Iain, any idea what might be wrong in our code base to cause these differences?

The function in question is:

    const c = (x, y) => {
        const yS = SPECIES[y.state]
        return yS.catalyticSupport[x.state] ? yS.catalyticSupport[x.state] * catalyticSupportAmount.value : 0
    }

It's small enough to inline, although it's not clear that we actually do.

I generated a CacheIRHealthReport, but nothing stood out. The only non-monomorphic IC is the JumpIfFalse for the ternary, which had one stub for int32 and one stub for null/undefined. The polymorphic types optimization should kick in there and generate a test that compares the hot types first, so that shouldn't be slow.

Running that function locally with made-up data, the LIR looks fine.

I don't see repeated bailouts.

Maybe we can revisit this when the profiler captures machine instructions.