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 <javascript:>> 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.
