> Thanks. Looking at this, the main module 2 is 23% larger. Looks like much of that is due to us exporting all the functions in the table (which limits dce). I think we don't need that for wasm shared modules, this is just something that wasn't optimized yet.
I guess in this example the thing that stands out to me more is that the JS file is almost 3x the size. This seems to be mostly because of a number of internal symbols including the following being exposed: var __ZN6animal8KittyCat16GetWhiskerLengthEv = Module["__ZN6animal8KittyCat16GetWhiskerLengthEv"] = asm["__ZN6animal8KittyCat16GetWhiskerLengthEv"]; Not only does this increase the file size, but also since those symbols are being exposed unnecessary parts of the internal structure are visible. Is this what you are referring to with "exporting all the functions in the table"? > I'd suggest opening issues on this and on memory growth not allowed in shared wasm modules (mentioned earlier in this thread), so that they are not missed, and hopefully someone can get to them soon. Okay, I will submit a couple of bug reports for these two cases. Thanks, David On Tuesday, September 12, 2017 at 5:31:21 PM UTC-7, Alon Zakai wrote: > > Thanks. Looking at this, the main module 2 is 23% larger. Looks like much > of that is due to us exporting all the functions in the table (which limits > dce). I think we don't need that for wasm shared modules, this is just > something that wasn't optimized yet. > > I'd suggest opening issues on this and on memory growth not allowed in > shared wasm modules (mentioned earlier in this thread), so that they are > not missed, and hopefully someone can get to them soon. > > On Mon, Sep 11, 2017 at 3:18 PM, <dtipp...@gmail.com <javascript:>> wrote: > >> All right. I was able to reproduce the problem with the sample at >> https://drive.google.com/open?id=0B462aSLeSsPMUFhnNW1iYzhjeHM . (created >> binaries also included in output folder) The issue doesn't really appear to >> be reproducible until some standard library logic is used. (in this case >> std::vector) >> >> Please let me know if anything is unclear in the sample. In my case I ran >> Emscripten on Windows using CMake to generate mingw32 makefiles. >> >> Thanks, >> >> David >> >> On Friday, September 8, 2017 at 10:05:39 AM UTC-7, Alon Zakai wrote: >>> >>> That's odd, can you make a small testcase showing the issue you are >>> seeing? That would help understand what's going on. >>> >>> Mode 2 in main and side modules should only keep alive things you >>> explicitly keep alive, so you may be hitting a bug in how we do that, or in >>> LLVM's dce. >>> >>> >>> On Thu, Sep 7, 2017 at 12:26 PM, <dtipp...@gmail.com> wrote: >>> >>>> Hmm, even with -s MAIN_MODULE=2 internal symbols are still being >>>> exposed. I see a large number of internal symbols in the .js file exposed >>>> in the following manner: >>>> var _internal_function_name = Module["_internal_function_name"] = >>>> asm["_internal_function_name"]; >>>> >>>> Most likely as a result the output files are still significantly larger >>>> than without -s MAIN_MODULE >>>> >>>> Default: 264 KB .js file. 6.6 MB .wasm file. >>>> MAIN_MODULE = 1: 7MB .js file 15MB .wasm file >>>> MAIN_MODULE = 2: 3MB .js file 8MB .wasm file >>>> >>>> Is this expected? >>>> >>>> Thanks, >>>> >>>> David >>>> >>>> On Thursday, September 7, 2017 at 11:13:12 AM UTC-7, dtipp...@gmail.com >>>> wrote: >>>>> >>>>> Yeah, sorry, I must have missed that comment in the documentation. Is >>>>> dead code elimination also disabled for side modules and if so is >>>>> SIDE_MODULE=2 expected to work? >>>>> >>>>> Thanks, >>>>> >>>>> David >>>>> >>>>> On Thursday, September 7, 2017 at 11:06:27 AM UTC-7, Alon Zakai wrote: >>>>>> >>>>>> Yes, linkable modules are larger by default because we disable dead >>>>>> code elimination (since something might be used from something it is >>>>>> linked >>>>>> to). See MAIN_MODULE mode 2, that can help (see docs in settings.js). >>>>>> >>>>>> On Thu, Sep 7, 2017 at 10:33 AM, <dtipp...@gmail.com> wrote: >>>>>> >>>>>>> Thanks, that allowed me to build. >>>>>>> >>>>>>> I noticed that by adding -s MAIN_MODULE=1 my wasm file size >>>>>>> increased from 6.5 MB to 14.6 MB. Is this kind of increase expected or >>>>>>> am I >>>>>>> doing something incorrect? For reference my build settings look like >>>>>>> the >>>>>>> following: >>>>>>> >>>>>>> emcc -s DISABLE_EXCEPTION_CATCHING=0 --llvm-lto 3 -s WASM=1 -s >>>>>>> EXTRA_EXPORTED_RUNTIME_METHODS=['UTF16ToString','stringToUTF16'] -Oz >>>>>>> libpdf_worker.so libPDFNetC.so -o ${WORKER_NAME}Wasm.js --bind -s >>>>>>> MAIN_MODULE=1 --js-library NextAfter.js -s ALLOW_MEMORY_GROWTH=1 -s >>>>>>> NO_EXIT_RUNTIME=1 -s TOTAL_MEMORY=50331648 -s >>>>>>> RESERVED_FUNCTION_POINTERS=10 -s EXPORTED_FUNCTIONS=<big list of >>>>>>> functions> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Thursday, September 7, 2017 at 1:00:14 AM UTC-7, jj wrote: >>>>>>>> >>>>>>>> Hmm, in WebAssembly, I believe that message should not be relevant >>>>>>>> anymore, and memory growth should be supported with dynamic >>>>>>>> linking. >>>>>>>> Or perhaps there was some reason that I can't remember now. You can >>>>>>>> try finding where that message comes out, and comment it out, it >>>>>>>> might >>>>>>>> apply only to asm.js case. >>>>>>>> >>>>>>>> 2017-09-07 9:58 GMT+03:00 <dtipp...@gmail.com>: >>>>>>>> > Hmm, I encountered an error: "memory growth is not supported with >>>>>>>> shared >>>>>>>> > modules yet". Unfortunately I don't really have the option to >>>>>>>> disable memory >>>>>>>> > growth. (since the modules memory usage is dependent on user >>>>>>>> input) Is there >>>>>>>> > any workaround for this error? If not is adding memory growth for >>>>>>>> shared >>>>>>>> > modules something that will be supported soon? >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > >>>>>>>> > David >>>>>>>> > >>>>>>>> > >>>>>>>> > On Tuesday, September 5, 2017 at 5:49:28 PM UTC-7, >>>>>>>> dtipp...@gmail.com wrote: >>>>>>>> >> >>>>>>>> >> Thanks, I will give it a try! >>>>>>>> >> >>>>>>>> >> David >>>>>>>> >> >>>>>>>> >> On Tuesday, September 5, 2017 at 4:57:43 PM UTC-7, Alon Zakai >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> To some extent yes. We have working dlopen() support, see >>>>>>>> >>> >>>>>>>> >>> https://github.com/kripken/emscripten/wiki/Linking >>>>>>>> >>> >>>>>>>> >>> However, it is not optimized yet, it uses a bunch of hacks. As >>>>>>>> a result >>>>>>>> >>> getting this working takes a bit more effort (see details on >>>>>>>> that page), and >>>>>>>> >>> it has more size and speed overhead than it should. This will >>>>>>>> be fixed >>>>>>>> >>> eventually with proper dynamic linking of wasm. >>>>>>>> >>> >>>>>>>> >>> On Tue, Sep 5, 2017 at 2:54 PM, <dtipp...@gmail.com> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Hi, >>>>>>>> >>>> >>>>>>>> >>>> My situation is this: >>>>>>>> >>>> >>>>>>>> >>>> I am dealing with a fairly large codebase and trying to make >>>>>>>> WebAssembly >>>>>>>> >>>> builds as small as possible to speed up loading times. >>>>>>>> (especially a problem >>>>>>>> >>>> on mobile) There are certain libraries that are rarely used >>>>>>>> and contribute a >>>>>>>> >>>> significant portion of the total size so my thought was to >>>>>>>> load these >>>>>>>> >>>> libraries only when their functions are first used. >>>>>>>> >>>> >>>>>>>> >>>> Given the above I was wondering if it is currently possible to >>>>>>>> >>>> dynamically and synchronously download wasm and load it using >>>>>>>> dlopen or >>>>>>>> >>>> equivalent on current browsers? This would be running in a >>>>>>>> worker so any >>>>>>>> >>>> synchronous wait would not cause the UI to hang. >>>>>>>> >>>> >>>>>>>> >>>> Thanks, >>>>>>>> >>>> >>>>>>>> >>>> David >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> > -- >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>> -- >>>> >>> >>> -- >> > > -- 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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
