6

Garbage-collected languages, such as Go and AssemblyScript, require shipping a runtime with the application to handle garbage collection. This results in much larger binary sizes than from languages without garbage collection. How do the binary sizes from various languages that compile to WebAssembly compare?

Improve this question
1
  • What did you discover when you tested it yourself?
    – mjwills
    Commented Mar 13, 2019 at 6:50

2 Answers 2

Reset to default
4

I found this website https://boyan.io/wasm-wheel/ that demos different languages running WebAssembly. The sizes on that page:

  • PHP 4.5MB
  • AssemblyScript 191B
  • C 186B
  • Go 1.5MB
  • Java 4.2KB
  • Kotlin 234KB
  • Rust 99KB
  • Python 13MB

As expected Go and PHP are large. Seems even Java and Kotlin get it right here, but maybe like Go their binary sizes balloon with the addition of more complex code.

Improve this answer
4
  • 2
    Rust output is larger than Java's. That's hard to believe.
    – Gurwinder Singh
    Commented Mar 6, 2021 at 10:03
  • @GurwinderSingh updated, although rust is still larger
    – maxm
    Commented Mar 6, 2021 at 13:54
  • Not a fair comparison for Java & Kotlin. That project uses an ahead-of-time compiler for those languages to convert them into javascript before converting into WebAssembly. that's why there's no bloat & it's smaller than a non-GC language like Rust.
    – Sami Fouad
    Commented May 4, 2021 at 10:10
  • 1
    Also small note: if Tinygo is used instead of the regular Go compiler, a simple "hello world" example can be as small as 575B. There is also compression available for the .wasm files for every language, so a 10MB file can easily be cut down to 1/2 or 1/3 the size with Brotli or gzip compression.
    – Sami Fouad
    Commented May 4, 2021 at 10:32
0

I can’t say about Go, but AssemblyScript has an optional GC which needs to be turn on manually btw. In addition, it can work even without any memory allocators handle linear memory directly (see https://developers.google.com/web/updates/2019/02/hotpath-with-wasm). In addition to all the final work makes binaryen which allow a lot of optimization passes targeted on code shrinkage. Even with memory allocator and builtin GC simple "hello world" example never become bigger than 2 kb becuse tlsf for example compiles to approx 1 kb, Incremental Tri-Color-Marking Garbage Collector even smaller.

Of course, all this will be unnecessary when these two proposals:

  1. https://github.com/WebAssembly/reference-types
  2. https://github.com/WebAssembly/gc

​​are implemented in WebAssembly.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.