This is a deeper understanding of the problem than I had, and explains the striking difference in speed between Pale Moon and Firefox that I've noticed on many JS-heavy sites, especially Facebook and similar. I'd thought it was the JS processing engine optimization, but I see now that it is much more likely poorly optimized fall-back code, poly-fills, and similar alternative solutions provided by the web sites that end up causing the problem.Moonchild wrote: ↑2023-03-07, 09:38Actually, Pale Moon is not "much slower than firefox" in how it operates.
...
Even just-in-time compilation is broadly the same making Javascript execution near-native code speed.
...
So where does this perceived slowness come from then? Well, the websites that are problematic do not have any meaningful content except what their scripting barfs out on the screen, so everything ends up being bottlenecked into content-translating scripting. Once again it's not that our scripting engine is slow; far from it. But what happens more often than not is that the scripting checks for specific native features and if even one is missing it will go into "fallback mode" (if they even have one) which will then assume nothing they want is supported and emulate it (through replacement, unoptimized javascript code).
This is actually great news, as things should just improve "magically" as Pale Moon checks those compatibility boxes and one day Facebook (and similar) might see all of the native features they are expecting and, poof, it'll just be unrecognizably fast.
(I had a sneaking feeling Pale Moon had a fork-point after the major JS improvements in Firefox ESR, but was convinced otherwise by my previous theory. I see now my theory was wrong and I'm happy to know the proper reasoning now. Thank you MC!)