3 ms·
One thing for old-school performance comparers to remember here is that WASM is very significantly cheaper than JavaScript to parse and compile. On an arbitrar
by chrismorgan 5y ago
One thing for old-school performance comparers to remember here is that WASM is very significantly cheaper than JavaScript to parse and compile.
On an arbitrary fairly weak phone, 15MB of WASM might take two seconds to compile, but it can do that while downloading, so that in practice your network link will probably be the limiting factor. So the transfer size is typically the figure to care about and the uncompressed size actually doesn’t matter all that much.
15MB of JavaScript on that same device might take ten seconds or even more to compile, and it largely can’t even start until it’s finished downloading it. Consequently, you need to care about both the transfer size and the uncompressed size, in different ways.
(My figures are super dodgy as I can’t find any recent concrete figures, but they should be in vaguely the right ballpark.)
This is all about comparing just the cost to the CPU; data transfer costs money too and takes time, and several megabytes transferred is inconvenient to many for reasons of cost or time, and decidedly wasteful.
Multiple megabytes even of WASM is still madness and folly for simple stuff like this, severely restricting its potential usefulness. Thank you for deciding not to ship something like that yourself.
- mumphster 5y agoThat applies if youre shipping a giant 15 meg blob of js (not saying some sites dont do this), a lot of the size also comes from css and other assets which still apply with shipping a wasm blob. I'm gonna guess that v8 can parse a 1-2 meg js file just as fast if not faster than the time it takes to download a 15 meg wasm blob or a 4 meg blob + decompress + parse outputted from golang. Like your last line says, shipping 15 megs of any kind of code makes no sense to me
- chrismorgan 5y agoWhen considering performance, some people presume that WASM is much the same as JavaScript; I’m just reminding them that this is not the case: WASM has better loading characteristics than JavaScript so that its cost per byte is much more like that of images than of JavaScript.
- oefrha 5y agoAs mumphster pointed out in a sibling, 15MB of wasm vs 15MB of javascript is an unfair comparison. For instance, my aforementioned app is a few hundred KB of uncompressed js when rewritten, not 15MB. Also, in my experience, a 15MB wasm blob has shit caching characteristics; it gets evicted all the time. An immutable few hundred KB js blob, on the other hand, can remain cached for much longer. Sure, you can use a service worker and its Cache API to make caching large blobs more predictable, but then shipping new code / cache invalidation becomes more annoying.