4 ms·
Some things. WASM binary size is highly dependent on optimization level. If your WASM is anywhere near the size of your JS, something is off with your compiler
by throwaway189262 5y ago
Some things.
WASM binary size is highly dependent on optimization level. If your WASM is anywhere near the size of your JS, something is off with your compiler settings. Since Rust and C++ are statically typed, compilers can use LTO to remove almost every unreachable instruction. JS, even with tree shaking, gets nowhere near this.
Default settings in Emscipten generate huge binaries. Rust without the "native" target or a bunch of configuration also does.
WASM bytecode is also more compact than JS. There's simply no reason the binaries should be even close to the same size.
The memory usage should also be different by and order of magnitude. WASM has basically no overhead above machine sizes for most types. Look at Benchmarks Game, memory use JS vs Rust. You should be seeing a difference close to that.
I can't speak for speed. But I can say I did a head-to-head comparison between the fastest pure JS PNG encoder I could find vs a C encoder transpiled to WASM, and the transpiled encoder was >10X faster.
It's hard to say if something is off in the benchmark or compilation but I find it hard to believe there's such a big difference between my tests and yours. Emcripten especially is not exactly easy to use and maybe a good place to look for size and speed optimization
- rkangel 5y ago> WASM bytecode is also more compact than JS. There's simply no reason the binaries should be even close to the same size. The author does explain this pretty well. For an exact 1:1 comparison, yes WASM beats JS for size. JS comes with built in functionality (e.g. a garbage collector) that doesn't cost any size, but in the WASM case needs to be brought along taking up space. Even if you don't want GC, you don't get any WASM 'standard library'.