This is wonderful news :) In my smallest-possible WebGL demos (https://floooh.github.io/sokol-html5/index.html) the .js part is about 2..3x times bigger than the .wasm part (after compression), for the triangle demo this is for instance (download size in Chrome) wasm 11.4 KByte, js 31.8 KByte. I think in those demos it's mostly the library_gl.js shim, not sure if there's much room for improvement though.
Improvements in other areas are also highly appreciated of course :) Cheers, -Floh. On Tuesday, 28 November 2017 02:10:41 UTC+1, Alon Zakai wrote: > > Recent discussions about our JS size [1] led to a plan for shrinking it, > and the first step along the plan [2] has a few PRs open for it. Since this > will change some things, we thought it made sense to post to the mailing > list about it. > > The background is that for a medium to large project (like a game engine) > we emit compact and efficient JS and asm.js/wasm. However, for a small > project we could do better, especially on the JS size, in part because > we've focused a lot on optimizing the compiled code (asm.js/wasm), but the > non-compiled JS can be significant in a small project. And as wasm > increases the interest in compiling to the web, we've been seeing more > people thinking about small projects these days, so we should do better > there. > > For example, a small program using some libc stuff (printf, malloc, etc.) > optimized for size is 5K of gzipped wasm and 9K of gzipped JS. The JS > should be smaller! :) > > The plan [3] for improving this will involve some breaking changes, since > part of the problem is that we export a lot of our runtime by default, so > it's emitted even if you don't use it. Breaking changes are never good, but > we've thought carefully about how to minimize the risk and annoyance here. > Feedback is very welcome. Overall, we hope to emit a compile-time error for > breaking changes when possible, which should make any changes users need to > make very simple. However, some things can't be checked at compile time. We > want to minimize the harm for those as follows: > > * In builds with ASSERTIONS enabled, emit a stub for the thing that is > being removed. Then if it is actually used, it will show an error message, > something like "this is no longer exported by default, you need to export > it yourself." It should be a simple fix given the message. > > * We already enable ASSERTIONS in -O0 builds by default. So the extra > runtime explanations would appear there as well. Hopefully most people, > when investigating something broken, will try either an unoptimized build > or a build with ASSERTIONS (as we already recommend doing so). > > * We'll document breaking changes in Changelog.markdown (which we really > should use more). > > * I think we're pretty responsive on the issue tracker in general, but we > can try to be extra-responsive about issues filed about these changes. > > To be more concrete, for example we would like to stop exporting getValue > and setValue by default [4]. The consequences of that change will be: > > * If you don't use getValue or setValue, nothing at all changes. > > * If you use Module['getValue'] then you must export it, using something > like -s EXTRA_EXPORTED_RUNTIME_METHODS=["getValue"]. If you don't export > it, you'll get the error message mentioned above at runtime, in -O0 or > ASSERTIONS builds, which can help quickly fix things. > > * If you use getValue directly (not indirectly on Module), then if you > are inside code that the compiler optimizes - anything in a pre-js, > post-js, or js-library - then it sees you are using it, and will not remove > it, so everything will still work. However, if you use it from another > script tag on the HTML file, which emcc did not see, then getValue will not > exist and you'll get an error - that is something that never worked with > closure compiler, though, and also has always been something we don't say > should work, as only things exported on Module should be relied upon from > the outside. > > In conclusion, these changes may cause breakage if you use these internal > runtime methods, but fixing the breakage is very simple, and we're trying > hard to make the fix obvious. I think the risk is worth it for the benefit > of emitting much more compact JS. > > Thoughts? > > - Alon > > [1] https://github.com/kripken/emscripten/issues/5794 > [2] https://github.com/kripken/emscripten/issues/5836 > [3] > https://github.com/kripken/emscripten/issues/5794#issuecomment-346421670 > [4] https://github.com/kripken/emscripten/pull/5839 > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
