2 ms·

> Surprisingly, including the _fmt_ library adds about 2MBytes to the size of the code. Part of including unicode package itself (transitively or otherwise) ha

> 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.

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.