Hacker News Reader

Comment by dlojudice | Hacker News Reader

"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

View on HN

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.

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

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

May be they can host all built in module to provide caching.

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.

init-time load has become a pet project of mine lately:

https://github.com/golang/go/issues/26775

A new person on the compiler might be working on that too as a warm-up task.

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

Or even some JS bundle sizes.

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.

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.

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.

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.

Images and videos are less important though.

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

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

Reply on news.ycombinator.com