4 ms·
PLEASE NOTE This is NOT a fair and honest comparison. The WebAssembly implementation pegs 100% of one CPU core (as monitored in htop) on my system until it is
by exikyut 9y ago
PLEASE NOTE
This is NOT a fair and honest comparison.
The WebAssembly implementation pegs 100% of one CPU core (as monitored in htop) on my system until it is completed.
The JS button sits between 66.2%-66.8% and 19-26% of one core depending on whether the tab is focused or not.
The JS version does not use Web Workers. I can, however, see two references to setTimeout(). This leads me to assume that the JS version is being slowed down so that the UI does not lock up.
Completely understandable, but patently dishonest, as there is no mention of this fact on the webpage.
The JS version should be reimplemented so it can run at 100% speed.
- ENGNR 9y agoIt's still an order of magnitude slower though at least on my machine
- exikyut 9y agoSame here too. I just think it's dishonest that there's no mention that the JS version is being throttled while the wasm version is not.
- DanRuta 9y agoI'm currently re-writing the JS version to not use the setTimeout functions, in favour of just running the whole thing in a WebWorker, to still maintain browser usability. I'm focusing more on a WebGL version, but once that's done, it should be a fairer comparison.