On Saturday, January 7, 2017 at 2:04:13 PM UTC-8, Brendan Bohannon wrote: > > I have recently been using Emscripten for building some personal projects > as a test, but have noted some various issues. > version = 1.35.0 >
You mention testing WASM. 1.35.0 doesn't support that. In any case try using the latest 1.37.x. > > slow compilation times: > * compiling takes a fairly long time if compared with native compilers, > such as MSVC or GCC. > * ex: when compiling a 200 kLOC program, compilation takes a decent number > of minutes. > ** program is most a basic Minecraft-style 3D engine (voxel-based). > ** it isn't that big, and MSVC (VS2015) compiles it in under a minute. > * can note: optimized JS output is about 8MB, vs ~ 60MB without > optimizations. > > general requests: maybe try to make compile times faster? > > Compilation, especially to size optimized JS will take longer than generating an optimized .exe due to needing to optimize textual javascript. I suspect most compilation time improvements will be focused on the native LLVM WASM backend, but I htink that's still WIP. You can try seeing if Side Modules ( https://github.com/kripken/emscripten/wiki/Linking#overview-of-dynamic-linking ) allow you to compile frequently modified code in a smaller JS subset. > misc: > * compiler seems to be imposing some C++ rules onto C for some reason. > Certain features of Emscripten require the use of a C++ compiler (embind for example) > * this can be addressed, but it was annoying needing to go over and stick > in extra type-casts on pointers and similar. > > also more/better debugging facilities would be nice, even if only > something like making "emrun" able to provide a GDB style interface. > > You can can give CyberDWARF a shot for better printing support, but it's still rough: https://kripken.github.io/emscripten-site/docs/debugging/CyberDWARF.html Expect WASM to deliver better debugging. In general I'd recommend having a project that can be built either for JS or Native and primarily debugging native. > > have observed that rendering and input-handling seem faster on Chrome, > whereas primarily CPU-based tasks seem faster on Firefox (but offset by it > being noticeably slower to respond to keys being pressed/released than in > Chrome). general start-up times are a lot faster in Chrome. > > however, I keep getting "browser ran out of memory" type error messages > (primarily in Chrome, which basically says something like "Aw, Snap! > Browser ran out of memory while trying to display website.") after a period > of time (~ 15-20 minutes), this being seemingly uneffected by the choice of > a 256MB or 512MB heap size (note: 256MB is about the minimum I can get away > with, with a 64-meter draw distance; in native land for a 256 meter > draw-distance memory use is generally around 1 GB, ...). > > You can get an overview of where else in your JS app you're consuming memory with a tool like Chrome's heap profiler: https://developer.chrome.com/devtools/docs/heap-profiling Firefox has a similar tool. Javascript has a maximum heap size of 1GB, so you'll have to stay under that for your JS allocated memory. WASM memory regions don't count against that (or at least can go beyond it). > > thoughts/comments?... > > > for anyone curious, I have a built version online from here: > https://cr88192.github.io/bgbtech_html/ > > I haven't pushed the changes for all this back up to GitHub yet, but > general source for the engine is here: > https://github.com/cr88192/bgbtech_engine2 > > -- 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.
