Uglify does take a lot more memory than the native optimizer. It's better to use the native one when possible. The only thing it can't be used for is to run on non-asm.js code (but that code tends to be much smaller anyhow so the native optimizer isn't needed).
You can try to use fewer cores, EMCC_CORES=x in the env, to use less memory. Also make sure to use a 64-bit node.js. Is this for custom optimization passes you wrote? On Wed, Sep 23, 2015 at 5:20 PM, arnab choudhury <[email protected]> wrote: > Hello there > > I am seeing some odd behavior when using emscripten to transpile a decent > size codebase to Javascript. Sometimes, Emscripten's JS optimizer hangs - > this doesn't happen all the time though. > > When the problem does occur, node.exe is taking up 1.2 to 1.3 Gb of memory > - I suspect that node's garbage collector is thrashing. I've narrowed down > the problem to a call to Uglify.parser.parse - it looks like the parser can > take up large amounts of memory and if we ever near the heap maximum for > node, all forward progress is lost - likely because of thrashing (the > thrashing part is speculation - I haven't been able to profile in the bug > scenario). > > Is this a known issue with Uglify's parser? Are there any workarounds? I > can resort to the native optimizer - but that seems to be mainly used for > local optimization passes - so I've had to use uglify's parser for global > optimization. > > Thoughts appreciated. > > Thanks, > Arnab > > -- > 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.
