JS and wasm shrinking (testcase #1)

[kripken]

This issue tracks part of our shrinking initiative, which is Option 1 from #5794. The goal is to shrink the JS and wasm we emit by default. See details in that previous discussion.

To get things started, I looked at one testcase - we should look at more, hence the testcase #1 in the title, this is just to get started. The testcase is a "pure computation" library,

#include <emscripten.h>

EMSCRIPTEN_KEEPALIVE
int add(int x, int y) {
  return x + y;
}

and I built it with -Os --closure 1 -g1 -s WASM=1, then counted lines in the JS. Starting point: 10K of wasm and 24K of JS when fully minified, or when built as I did with -g1 for convenience, it is 32K, in 1,143 lines. In more detail:

• 232 lines: String and array utilities, ccall, cwrap Less default runtime exports #5892 (need more)
• 132 lines: wasm glue. Clean up wasm glue #5859 Remove the asmGlobal if not using asm.js #5907 (may need more)
• 109 lines: ENVIRONMENT setup stuff.
• 102 lines: Calling main + the hooks around that. Don't emit code to call main if there is no main #5850 (need more)
• 88 lines: Runtime object. De-runtime-ification #5954
• 55 lines: getValue/setValue. do not export getValue and setValue by default #5839
• 55 lines: Syscalls.
• 55 lines: Export stuff from asm (all the Module.x = get the thing from asm.x etc).
• 44 lines: Stack trace support. ifdef demangle JS support code, include it only when needed #5857
• 44 lines: addOnPreRun, runDependency etc, startup ordering stuff.
• 35 lines: Memory and view creation.
• 34 lines: allocate()
• 27 lines: Math fallbacks (imul, clz, trunc). Remove legacy support for polyfilling Math.clz32, imul, trunc #5837
• 27 lines: Mem init file loading. Don't inclue mem init loading code when it is inside the wasm anyhow #5844
• 18 lines: invoke/dynCall stubs.

Also

• Meta-DCE Meta-DCE for JS+WASM #5919

If you want to work on one of these, open an issue or a PR, and we can add a link from here.

[curiousdannii]

I like this idea, and I might try to submit a PR for one or two.

I do think changes of this nature warrant a bump to version 1.38.0 if not 2.0.0. With no release descriptions or a dedicated news blog it will be important to signal that these changes are arriving.

Would it help to have a staging branch for them to be merged into before they all get merged into incoming?

[kripken]

We can mention this on the mailing list to get more attention, good idea. We can also try to have more tagged versions around them (helps bisection etc.), but that's being held up by problems on the bots that we just need more help with keeping green (so not sure if that will change).

Otherwise though I think that these changes shouldn't be that dangerous - at least the 3 PRs open so far are not - because they will give very clear error messages when assertions are on (and also in -O0 mode where assertions are on by default). Any breakage people encounter should be brief.

Any change that is more dangerous than that should be handled even more carefully, but hopefully we won't run into such a thing.

[kripken]

Mentioned on the mailing list: https://groups.google.com/forum/#!topic/emscripten-discuss/OY_6JCIjimc

[kripken]

#5919 (meta-DCE, DCE across js+wasm) helps very significantly on this, shrinking the .js by 5% and the .wasm by 84%.

[kripken]

This testcase is basically done - we emit a tiny 42 byte wasm for it (compared to 10,837 bytes before), the best possible. I'm preparing a blogpost about the progress.

The work here has also helped other testcases as well, we should focus on them next.