A word about my C64 emulator: this is very CPU hungry, partly because the 6502 emulation uses a cycle-stepped model (<a href="https://floooh.github.io/2019/12/13/cycle-stepped-6502.html" rel="nofollow">https://floooh.github.io/2019/12/13/cycle-stepped-6502.html</a>), this causes the 6502 emulation to store and load context in each cycle which pretty much eliminates the opportunity that emulator state can be kept in registers across cycles, it also does an indirect jump for each cycle instead of just once per instruction. More importantly though, the VIC-II emulation isn't very optimised, every cycle updates the entire chip state, sprite units and all (the VIC-II emulation dominates the per-frame budget much more than the CPU) - in general the implementation of the entire emulator is fairly straightforward, but also fairly brute-force.<p>When looking at emulator benchmarks it's always important to also look at how the emulator has been implemented, and what compromises an emulator might make to balance between performance, accuracy and "design purity" (e.g. the cycle-stepping CPU model isn't all that useful in practice, except that it is 'more pure' and interesting from an emulator-design point-of-view). In comparison to those implementation differences, the performance difference between WASM and JS should be mostly negligible.