Go to https://bruno-simon.com/

Play with the demo for 10-15 seconds to get a reasonable profile

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

There is something strange with this profile indeed.
While the highest function is only 19% of the total execution, the profiler sporadically reports it as being 80% baseline / 20% Ion. This is roughtly true independently of the window of focus in the profile. In the mean time, no bailout or invalidation are reported as frequently.

On the other hand, the nursery collections are extremely frequent.
Thus, if the nursery collection implies that we do not re-enter Ion, that would be an explanation, but we might also want to double check what is going on.

Iain, would you mind looking at what is going on?

The function in question is very boring:

o.prototype.needBroadphaseCollision = function(e, t) {
    return 0 != (e.collisionFilterGroup & t.collisionFilterMask) && 
           0 != (t.collisionFilterGroup & e.collisionFilterMask) && 
          (0 == (e.type & a) && e.sleepState !== i.SLEEPING || 
           0 == (t.type & a) && t.sleepState !== i.SLEEPING)
}

It appears to come from here.

The caller appears to be this function, which contains the comment "// Naive N^2 ftw!".

So it seems quite plausible to me that this is an inefficiently written website, and that's why this code is hot.

The remaining mystery is why the profiler is reporting that we're spending all our time in baseline. It's possible this is just a tools problem. I know Jan is currently working on some fixes to make the profiler data more accurate (Ion ICs are currently reported as baseline, IIRC). Maybe we can revisit this once those fixes have landed, or when the assembly view is available in the profiler, to see if we can get any insight.

Yes I agree this could be the same issue as bug 1799806.

Profile with latest Nightly: https://share.firefox.dev/3Ve9bND