5 ms·

"Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the

"Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the resulting size is at minimum around 2 MB, or 500 KB compressed." considering it includes the runtime, this isn't a large file compared to images / videos you find on the web today

rounce 8y ago
Or even some JS bundle sizes.
bradfitz 8y ago
And this is temporary. In the future we should be able to both do better size-wise & also to generate multiple WebAssembly output modules, perhaps one per Go package, to enable better (more fine-grained) caching.
- bradrydzewski 8y ago
  I really enjoyed following the WASM CLs. A huge effort from both neelance and the reviewers. Thanks to everyone that donated their time to make this happen! If the compiler output is deterministic perhaps the Go runtime and Go standard libraries could be bundled as modules, allowing for aggressive cache policies. Maybe even served from a central CDN. Just a thought ...
- kodablah 8y ago
  > generate multiple WebAssembly output modules, perhaps one per Go package With Go disallowing circular package refs and WASM support for func imports this should be doable. However, they'll all essentially have to share a single imported memory instance, so there'll be some central runtime heap coordination which is plenty reasonable.
- iamgopal 8y ago
  May be they can host all built in module to provide caching.
MatthewPhillips 8y ago
Images and videos are less important though.
xienze 8y ago
That sounds to me like the size of Hello World. Start including more and more of the runtime and it’ll get quite a bit bigger, much the same as native Go binaries.
- kodablah 8y ago
  IIRC, hello world that uses println is actually smaller. It's once you import fmt and unicode directly or indirectly (most libs) where those reported sizes start from.
- bradfitz 8y ago
  It grows but not super fast. Like the other comment said, once you include the runtime and Unicode tables, that's a fair bit of it.
kodablah 8y ago
I still think it's too big and look forward to size reduction. One of the things I found was also a bit heavy is init with tens of thousands of instructions to initialize the unicode package with those dozens of structs.
- bradfitz 8y ago
  init-time load has become a pet project of mine lately: https://github.com/golang/go/issues/26775 https://github.com/golang/go/issues/26775 A new person on the compiler might be working on that too as a warm-up task.
  - kodablah 8y ago
    Nice. Looking at what's exposed in the unicode package (did a tad bit of research [0]), there may be limited opportunities to reduce that since the structs are exposed. Maybe fewer goroutine suspend points between cpu-only tasks inside init, I dunno, not very familiar. Maybe a bunch of structs initialized with only const exprs in their fields could be eval'd at compile time and become a data section in the binary (until mutated maybe or just copied from the data section since there're no public immutable vars). 0 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622
adamnemecek 8y ago
You can’t compare images with code. 500kb is a ton of code.
- codycraven 8y ago
  You're right, but 500kb of Wasm is nowhere near as bad as 500kb of JS.
e3b0c 8y ago
Now that the binary size issue has finally come into the spotlight thanks to the WebAssembly, hopefully, embedded devs could benefit from the future efforts of size reduction too.

rounce 8y ago

Or even some JS bundle sizes.

bradfitz 8y ago

And this is temporary. In the future we should be able to both do better size-wise & also to generate multiple WebAssembly output modules, perhaps one per Go package, to enable better (more fine-grained) caching.

bradrydzewski 8y ago
I really enjoyed following the WASM CLs. A huge effort from both neelance and the reviewers. Thanks to everyone that donated their time to make this happen! If the compiler output is deterministic perhaps the Go runtime and Go standard libraries could be bundled as modules, allowing for aggressive cache policies. Maybe even served from a central CDN. Just a thought ...
kodablah 8y ago
> generate multiple WebAssembly output modules, perhaps one per Go package With Go disallowing circular package refs and WASM support for func imports this should be doable. However, they'll all essentially have to share a single imported memory instance, so there'll be some central runtime heap coordination which is plenty reasonable.
iamgopal 8y ago
May be they can host all built in module to provide caching.

MatthewPhillips 8y ago

Images and videos are less important though.

xienze 8y ago

That sounds to me like the size of Hello World. Start including more and more of the runtime and it’ll get quite a bit bigger, much the same as native Go binaries.

kodablah 8y ago
IIRC, hello world that uses println is actually smaller. It's once you import fmt and unicode directly or indirectly (most libs) where those reported sizes start from.
bradfitz 8y ago
It grows but not super fast. Like the other comment said, once you include the runtime and Unicode tables, that's a fair bit of it.

kodablah 8y ago

I still think it's too big and look forward to size reduction. One of the things I found was also a bit heavy is init with tens of thousands of instructions to initialize the unicode package with those dozens of structs.

bradfitz 8y ago
init-time load has become a pet project of mine lately: https://github.com/golang/go/issues/26775 https://github.com/golang/go/issues/26775 A new person on the compiler might be working on that too as a warm-up task.
- kodablah 8y ago
  Nice. Looking at what's exposed in the unicode package (did a tad bit of research [0]), there may be limited opportunities to reduce that since the structs are exposed. Maybe fewer goroutine suspend points between cpu-only tasks inside init, I dunno, not very familiar. Maybe a bunch of structs initialized with only const exprs in their fields could be eval'd at compile time and become a data section in the binary (until mutated maybe or just copied from the data section since there're no public immutable vars). 0 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622

adamnemecek 8y ago

You can’t compare images with code. 500kb is a ton of code.

codycraven 8y ago
You're right, but 500kb of Wasm is nowhere near as bad as 500kb of JS.

e3b0c 8y ago

Now that the binary size issue has finally come into the spotlight thanks to the WebAssembly, hopefully, embedded devs could benefit from the future efforts of size reduction too.