Native speed? JavaScript is significantly faster than WASM at certain tasks. Especially things related to image/video processing. takahirox.github.io/WebAssembly-be...
On the video grayscale example in my version of Google Chrome, JavaScript is 4-5x faster than WASM.
This is the quickest benchmark. I bet what is slowing WASM is that it is repeatedly called from JS. I wonder what the result would be if the main loop was in WASM, ran with wasmtime
Javascript can run at native speed as well, if the engine optimizes it. On the other hand, I'm not sure what's in your wasm binary but I'm certain there's quite a bit of emscripten stuff in there.
You'd be better of using a language that directly compiles to wasm (maybe assemblyScript?) instead of this toolchain which gives you half a C std lib as well.
Add to that the aforementioned problems with calling from JS into wasm and back and the overall very concise code which the JS engine probably optimizes instantly, and it makes total sense that the overhead outweighs the benefit.
I wouldn't use wasm to replace 5 lines of JS just because it's possible. I think JS is still seen as an interpreted language, when performance in many cases is near native.
You can use wasm in cases where you want SIMD, for example, or when you want absolute consistency across all browsers in terms of execution time.
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.
Native speed? JavaScript is significantly faster than WASM at certain tasks. Especially things related to image/video processing. takahirox.github.io/WebAssembly-be...
On the video grayscale example in my version of Google Chrome, JavaScript is 4-5x faster than WASM.
This is the quickest benchmark. I bet what is slowing WASM is that it is repeatedly called from JS. I wonder what the result would be if the main loop was in WASM, ran with wasmtime
Javascript can run at native speed as well, if the engine optimizes it. On the other hand, I'm not sure what's in your wasm binary but I'm certain there's quite a bit of emscripten stuff in there.
You'd be better of using a language that directly compiles to wasm (maybe assemblyScript?) instead of this toolchain which gives you half a C std lib as well.
Add to that the aforementioned problems with calling from JS into wasm and back and the overall very concise code which the JS engine probably optimizes instantly, and it makes total sense that the overhead outweighs the benefit.
I wouldn't use wasm to replace 5 lines of JS just because it's possible. I think JS is still seen as an interpreted language, when performance in many cases is near native.
You can use wasm in cases where you want SIMD, for example, or when you want absolute consistency across all browsers in terms of execution time.