Go to : https://gateway.fxhash2.xyz/ipfs/QmZP5QVa4ypazrCtAZ4RLMYoDPEraMFA3BdKWoVQVMyv23/?fxhash=oogdTqrmtUV24CEVMQLje6W1jZrSNC1oRpKQfSBvQ4zv5LW9FNF

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

FWIW, the profiler appears to suggest that half of the time is spent in gfx (canvas) code. To remove the effect of that, I enabled the experimental gpu-canvas, and that seemed to improve the demo a bit.

Profile with gpu-canvas : https://share.firefox.dev/3YpFWta

Glancing at the flame graph of the profile in comment 1 suggests bug 1805199 could help here too, because we're calling getters under GetName ICs. We should retest after that lands.

Profile with latest nightly: https://share.firefox.dev/3V0IT0F

To put this in more perspective, here is a profile with gpu-canvas disabled : https://share.firefox.dev/3BJv9QO

This shows that each "block" of JS is ~80-90ms long. Compare this with the profile in comment #0, which shows each block takes 180-190ms.
This indicates that the patch from bug 1805199 reduced the time spent in JS by ~50%.

(In reply to Mayank Bansal from comment #4)

To put this in more perspective, here is a profile with gpu-canvas disabled : https://share.firefox.dev/3BJv9QO

This shows that each "block" of JS is ~80-90ms long. Compare this with the profile in comment #0, which shows each block takes 180-190ms.
This indicates that the patch from bug 1805199 reduced the time spent in JS by ~50%.

Yeah, the flame graph shows a lot of time in canvas code now. I don't see any obvious JS perf cliffs. Maybe fixing bound function overhead would help some. This bug will also be easier to investigate when we have JIT code in the profiler.