There's been a steady march of performance improvements in Spidermonkey, though they haven't gotten very much press. They've been rearchitecting most of the in

There's been a steady march of performance improvements in Spidermonkey, though they haven't gotten very much press. They've been rearchitecting most of the inline caches so there's more sharing between the baseline and optimizing compiler and less in the way of performance cliffs. See https://bugzilla.mozilla.org/show_bug.cgi?id=1259927 https://bugzilla.mozilla.org/show_bug.cgi?id=1259927 and its dependencies (https://bugzilla.mozilla.org/showdependencytree.cgi?id=1259927&hide_resolved=0 https://bugzilla.mozilla.org/showdependencytree.cgi?id=12599... for the dependency view). Things like https://bugzilla.mozilla.org/show_bug.cgi?id=1328140 https://bugzilla.mozilla.org/show_bug.cgi?id=1328140 led to significant improvements to the sort of megamorphic code you commonly see in frameworks (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1328140#c14 https://bugzilla.mozilla.org/show_bug.cgi?id=1328140#c14 shows 25% improvements on Ember benchmarks). This work has been ongoing; a bunch of it landed in 53, more in 54, and more has been landing since. What makes it a bit harder to advertise is that it's aiming at reducing performance cliffs and improving the chance that real-life code lands on fast paths, not on improving the performance of those already-fast paths. WebAssembly is where the "make the fast bits faster" action is, mostly.