I see. Ok, then the issue is that js opts are needed for emterpretify. In the debug output we show "enabling js opts for EMTERPRETIFY" if they were not enabled already. In other words, emterpretify forces js opts, which affects minification.
On Thu, Dec 29, 2016 at 7:44 AM, <[email protected]> wrote: > You were right with the hint about the whitespaces. > We set the js-opts flag to 0, which seems to disable minification. > > I did a search for do_minify() in the emcc.py file, it looks like if the > EMTERPRETIFY flag is set minification is done independently of the js-opts > flag: > https://github.com/kripken/emscripten/blob/6dc4ac5f9e4d8484e273e4dcc554f8 > 09738cedd6/emcc.py#L1999 > > I am not (yet) familiar with python, so I am not 100% sure if I correctly > understand the code, but it fits my observations. > > For us the solution is to remove the js-opts=0 parameter, let me know if I > can help you any further fixing the inconsistency regarding the > EMTERPRETIFY flag. > > Thanks, > Harald > > On Wednesday, December 28, 2016 at 2:09:04 AM UTC+1, Alon Zakai wrote: >> >> That is very surprising, yeah. Enabling the emterpreter should only >> reduce asm.js size by moving functions into the binary bitcode file, but >> unless your main is 40MB, that can't explain this ;) >> >> Emterpreter mode does change a few optimizations, which in theory could >> affect code size. It enables localCSE for example which is off by default. >> But also I wouldn't expect a huge change. >> >> Is there perhaps an obvious difference, like one of the files has >> whitespace and the other doesn't? (which would be a bug in emscripten) If >> not, you can run python tools/find_bigfuncs.py on the js files, that >> prints a list of functions by size, maybe some obvious difference will >> appear there. >> >> >> On Tue, Dec 27, 2016 at 3:03 PM, <[email protected]> wrote: >> >>> Hi, >>> >>> in the first version of our Emscripten port we used the Emterpreter in >>> order to replace our synchronous downloads using emscripten_wget_data(). >>> In the meanwhile we wanted to get rid of the Emterpreter and refactored >>> our codebase to support asynchronous downloads, but we realized that >>> suddenly the code size (.asm.js file) increased a lot. >>> >>> As a workaround we added the flags "-s EMTERPRETIFY=1 -s >>> EMTERPRETIFY_WHITELIST='[\"_main\"]'", which basically only passes the >>> main function to the emterpreter. >>> This reduced our asm.js file from 59 MB to 18 MB. >>> >>> I would not expect such a huge difference... I would be very happy to >>> hear your opinions? >>> The only explanation I would have is that the emterpreter disables some >>> heavy inlining, but still I think it is quite a lot. Moreover, as far as I >>> understood the emterpreter post-processes the generated asm.js code, so it >>> should only affect the code size of our main function, right? >>> >>> Any ideas in which direction I could further investigate? >>> Is it possible to generate a list of symbols, which I could use for >>> generating a diff from both version? Maybe this might help me to find out >>> more about the additional 40 MB code.... >>> >>> Thanks in advance, >>> Harald >>> >>> -- >>> 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. > -- 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.
