4 ms·
Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins? Go binaries, being static and embedding the whole go r
by oelmekki 9y ago
Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins?
Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though.
Is this something we will have to deal with? Or will this be a lesser featured go implementation?
- uluyol 9y agoI don't know much about wasm, but I imagine that most wasm binaries will be statically linked. The runtime does add overhead but I'd like to know how much compared to what you see with reasonably complex rust wasm code.
- oelmekki 9y agoYeah indeed, and if web development prefigure anything for wasm, we can expect apps to quickly have a lot of dependencies built in. I guess we'll get used again to "please wait, loading" screens :)
- pjmlp 9y agoI still get "please wait, loading" screens in JS heavy sites, specially those that go to the extreme of using JS to display static text.
- cbluth 9y agoIf you read the document link seen in the article you will see that one of their priorities is focusing on efficiency and size output of wasm.
- jayd16 9y agoHmm, maybe language runetimes can be dynamically linked and hosted by the language maintainers. Everyone imports the official library so the odds of the user already having most of everything cached is high.
- hawski 9y agoAren't cache gained savings a myth? Browsers have cache in magnitude of tens of megabytes and most sites have different versions of everything.
- netheril96 9y agoWell, subresource integrity was not a thing before.
- oelmekki 9y agoThis would be cool: shared objects over internet. Interesting direction to explore.
- brobinson 9y agoHalf the size of Go binaries you encounter in the wild are debugging symbols. Compile without them and use `upx --ultra-brute` and the binary will be about ~15% of its original size. You still get goroutine stack traces from panics without the debugging symbols.
- oelmekki 9y agoI didn't know go compiler allowed to build without those, thanks. I've just tried on a go binary that was 2.4MO. After building it with `go build -ldflags=-s .`, it's 1.6MO. After stripping with upx, it's 480ko (and still works, and has panic stack traces).
- killercup 9y agoPlease note that upx also compresses your binary contents and decompresses it at runtime. When downloading a WASM file over HTTP, the server can gzip it transparently. It'd be interesting to compare the effects on the size with what upx does (which is more specialized than gzip).
- oelmekki 9y agoI see, thanks. I used vanilla `strip` on my binary and it did not produce any size gain (so the strip flag of go compiler is plenty enough). Indeed, given how browsers already handle gunziping resources, it's probably best to rely on it. My binary, stripped by the go compiler and gziped, is 525ko (against 480ko using upx).
- yjftsjthsd-h 9y agoCould it also be that Go encodes symbols in a way that strip can't read, or is is just standard ELF stuff?
- brobinson 9y agoDon't forget the "-w" linker flag, too.