Figure out Wasm Binary Diff/Patch for Caching Parts of Wasm Binaries; or Domain-Specific Compression about vugu

[bradleypeabody]

Another observation on this is that the wasm code emitted right now by the Go compiler uses a loop algorithm http://troubles.md/posts/why-do-we-need-the-relooper-algorithm-again/ to allow the necessary jump/resume functionality to get things like panic/defer/recover/goroutines to work. And although there is not much we can easily do about the runtime performance, this may be a clue to some excellent domain-specific compression ideas. Nested blocks and local.get/local.set and a few other instructions consume portions of the generated code. It might be possible to use something as simple as a predefined dictionary with flate to get good compression ratios. Some testing should be done. There are also potentially other repetitive patterns that could lend themselves to compression, like br N ... end ... br N-1 ... end ... br N-2 ... end and so on.

This sort of compression could prove even more useful than trying to break up and cache different packages.

[bradleypeabody]

It would also be really helpful to have an analysis tool which showed what functions and packages were consuming the most space. Disassembling a program and just measuring the byte size of each package would be really helpful. For example the Vugu website binary has loads of syntax highlighting code in it where I only need one of the many included, and the linker seems to have been unable to optimize the others way (probably because of import side-effects/init).

With good domain-specific compression and visibility about what is bloating the code, this might mitigate the binary size situation significantly.