5 ms·

I've been playing with compiling Go into WASM for the last year. The size of the "binaries" created is entirely based on which libraries you include. Surprisi

by smoyer 6y ago

I've been playing with compiling Go into WASM for the last year. The size of the "binaries" created is entirely based on which libraries you include. Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code. Once you include the relatively few libraries you need, you can write a ton of code and the size of the code effectively stops growing.

kodablah 6y ago
> Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code. Part of including unicode package itself (transitively or otherwise) has a ton of package-level vars that bloat the WASM. Also, they slow down init because a bunch of code has to be run to initialize them. Also, due to the fact that WASM doesn't have arbitrary jumping, in order to support coroutine yielding and resumption, Go's WASM support puts big br_tables[0] at the top. A while back, I brought up some efficiency concerns w/ data size and init instruction count[1] but they were dismissed as WASM concerns not Go ones and there weren't any easy/obvious wins. Also a while back, I used an interpreter to run the Go WASM up until actual main, then bake in the data that was initialized and remove init for packages where I didn't need their values[2]. I kinda gave up on using Go and WASM after all of that, but there is real room for improvement there. 0 - https://webassembly.github.io/spec/core/exec/instructions.html#xref-syntax-instructions-syntax-instr-control-mathsf-br-table-l-ast-l-n https://webassembly.github.io/spec/core/exec/instructions.ht... 1 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622 2 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake
- smoyer 6y ago
  That's some great insight! I just learned to avoid certain packages altogether and I've been living with the results. Precomputing init() is an interesting idea and I could see it both increasing or decreasing the resulting binary depending on what's in it (similar to how running LZW compression on an already compressed value will often create a larger result). Of course, you also need to consider the init() execution time and I've generally built my "main" application to load really fast and then load sub-applications as libraries in the background. Note that these are experiments and I don't have a major WASM-based UI in production.
kevingadd 6y ago
Dependencies are the killer for webapps as a whole, and the general deficiency of web platform APIs is a big part of the problem. Want internationalization? Better compile ICU and ship 5+mb worth of code and data with every app, because the web platform is an absolute disaster for anyone who doesn't speak English. Want cryptography? Well, you can get it as long as you rewrite all your code to call out to JS and use async APIs for a synchronous operation. Want to decompress GZIP or Brotli? Time to compile those too and ship big blobs because the browser won't let you access its compression codecs either.

by smoyer 6y ago

kodablah 6y ago

> Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code. Part of including unicode package itself (transitively or otherwise) has a ton of package-level vars that bloat the WASM. Also, they slow down init because a bunch of code has to be run to initialize them. Also, due to the fact that WASM doesn't have arbitrary jumping, in order to support coroutine yielding and resumption, Go's WASM support puts big br_tables[0] at the top. A while back, I brought up some efficiency concerns w/ data size and init instruction count[1] but they were dismissed as WASM concerns not Go ones and there weren't any easy/obvious wins. Also a while back, I used an interpreter to run the Go WASM up until actual main, then bake in the data that was initialized and remove init for packages where I didn't need their values[2]. I kinda gave up on using Go and WASM after all of that, but there is real room for improvement there. 0 - https://webassembly.github.io/spec/core/exec/instructions.html#xref-syntax-instructions-syntax-instr-control-mathsf-br-table-l-ast-l-n https://webassembly.github.io/spec/core/exec/instructions.ht... 1 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622 2 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake

smoyer 6y ago
That's some great insight! I just learned to avoid certain packages altogether and I've been living with the results. Precomputing init() is an interesting idea and I could see it both increasing or decreasing the resulting binary depending on what's in it (similar to how running LZW compression on an already compressed value will often create a larger result). Of course, you also need to consider the init() execution time and I've generally built my "main" application to load really fast and then load sub-applications as libraries in the background. Note that these are experiments and I don't have a major WASM-based UI in production.

kevingadd 6y ago

Dependencies are the killer for webapps as a whole, and the general deficiency of web platform APIs is a big part of the problem. Want internationalization? Better compile ICU and ship 5+mb worth of code and data with every app, because the web platform is an absolute disaster for anyone who doesn't speak English. Want cryptography? Well, you can get it as long as you rewrite all your code to call out to JS and use async APIs for a synchronous operation. Want to decompress GZIP or Brotli? Time to compile those too and ship big blobs because the browser won't let you access its compression codecs either.