Yeah, I see similar things when compiling say tests/gles2_conformance.cpp (with something like -O2 -s WASM=1 --closure 1), the JS is over 2x bigger than the wasm. Looking in the code it's actually mostly SDL and browser integration that is the cause, less GL - we should look into that.
On Mon, Nov 27, 2017 at 10:41 PM, Floh <[email protected]> wrote: > 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#issuecomme >> nt-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. > -- 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.
