Thanks for the quick reply, Alon! Will bisect and report on my findings. Alas that probably means re-building emscripten-fastcomp a couple of times...
On Monday, April 6, 2015 at 5:51:34 AM UTC+10, Alon Zakai wrote: > > Any reason not to use a binary mem init file, which is optimal in terms of > code size? > > But I don't remember us changing anything about the text memory allocate > calls, though, so that's strange. Can you narrow it down to which version > the regression happens in? > > - Alon > > > On Sun, Apr 5, 2015 at 3:52 AM, Soeren Balko <[email protected] > <javascript:>> wrote: > >> I noticed that the Javascript "binary" that is generated by the latest >> emscripten from incoming (combined with the corresponding >> emscripten-fastcomp, emscripten-fastcomp-clang versions) is a lot larger >> than what it used to be a while ago (I did not update my local emscripten >> fork for 2 months or so). From the looks of it this is due to the fact that >> what used to be multiple allocate(...) calls is now one massive >> allocate(...) call with recurrent intermittent sequences of 0. >> >> I basically updated my emscripten fork to benefit from the new >> ALLOW_MEMORY_GROWTH flag. Does the latter have anything to do with the >> single allocate(...) call? >> >> Soeren >> >> -- >> 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] <javascript:>. >> 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.
