Try writing something much more compute-expensive, like a particle simulator, raytracer, or fractal renderer.
The reason this is important is — as already mentioned — that the interface involves a lot of overhead, so calling it so frequently for something already so fast in JS is wasteful.
Consider this alongside the fact that V8 has many optimisations and that the standard library is mostly backed by native code: it's hardly surprising that JS competes.
Finally (also as noted by others), compiling in release mode is important here. This takes slightly longer but makes the comparison much more fair, because your WASM actually has a chance of being optimised to the point the JS and the native code behind it already is.
I think you've raised a lot of very insightful points. I definitely agree that the library I chose probably wasn't the best, and I wasn't too aware of the interface overhead (so I guess I learnt something here!). At the end of the day, the only computation happening was incrementing a counter, so as you said, modern JavaScript engines already do a fairly good job at optimising that!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Try writing something much more compute-expensive, like a particle simulator, raytracer, or fractal renderer.
The reason this is important is — as already mentioned — that the interface involves a lot of overhead, so calling it so frequently for something already so fast in JS is wasteful.
Consider this alongside the fact that V8 has many optimisations and that the standard library is mostly backed by native code: it's hardly surprising that JS competes.
Finally (also as noted by others), compiling in release mode is important here. This takes slightly longer but makes the comparison much more fair, because your WASM actually has a chance of being optimised to the point the JS and the native code behind it already is.
Thanks for the comment!
I think you've raised a lot of very insightful points. I definitely agree that the library I chose probably wasn't the best, and I wasn't too aware of the interface overhead (so I guess I learnt something here!). At the end of the day, the only computation happening was incrementing a counter, so as you said, modern JavaScript engines already do a fairly good job at optimising that!