1. In MAIN_MODULE 2, we do perform LLVM dce normally, but we do still export everything that is left, because we don't know what the side module will need. Yeah, this can be a lot of unnecessary space, perhaps there should be an option to not do that - but I worry about complexity and usability here.
2. Your call_from_FUNCTION_TABLE_i methods sound like the dynCall methods that already exist. It's possible we can optimize to use those, although I think there was another reason we needed to export the function table elements. If so, there is a test, so you can disable that and run the test_dylink* test_dlfcn* tests to see what breaks. 3. Yeah, SIDE_MODULE 2 mode makes sense to add, I think. On Tue, May 16, 2017 at 10:20 AM, Qwerty Uiop <[email protected]> wrote: > Hi. > > I tried modularizing the project that I work on and discovered that sizes > of the resulting js files were way too large compared to the size of the > single js file compiled without modules. E.g. the module-less js was about > 15Mb, while separating about 10% of the code as a side module gave a 40Mb > main module and a 13Mb side one. I did some investigations and found out > that: > 1) For the main module EXPORT_ALL is always forcibly set to 1 even if > MAIN_MODULE is 2. Doesn't it contradict the purpose of the "MAIN_MODULE=2" > mode, where all required functions must be explicitly exported and the rest > are DCEd? Is it an oversight? > > 2) When I comment out the "EXPORT_ALL=1" line, the main module shrinks to > ~20Mb. Several of those megabytes are occupied by the line "return { xxx: > xxx, ...}" at the end of the asm part of the js and by the lines that > recreate the function tables outside of the asm part. The reason for them > being so big is that the main module has to make its entire function tables > available outside of the asm part, and to do so it exports all the > functions that it implements, and the exported names are never minified. To > work around the problem I tried, instead of exporting all the functions > directly, to define and export functions of the form: > function call_from_FUNCTION_TABLE_i...(funcIndex, ...) { > return FUNCTION_TABLE_i...[funcIndex](...) | 0; > } > and then use them to fill the tables outside of asm part. It worked for > me, though I didn't try to run Emscripten's own tests yet. The question is > - is the workaround OK? (it adds an overhead of an additional intermediate > function call on all inter-module calls). > > 3) The side module is so big, since the code is never DCEd fully. Perhaps > side modules should also have the second mode where only functions > specified by EXPORTED_FUNCTIONS are kept alive? > > -- > 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.
