Skip to content

WASM shared modules export unnecessary symbols even with -s MAIN_MODULE 2 #5586

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Auron52 opened this issue Sep 13, 2017 · 3 comments · Fixed by #7371
Closed

WASM shared modules export unnecessary symbols even with -s MAIN_MODULE 2 #5586

Auron52 opened this issue Sep 13, 2017 · 3 comments · Fixed by #7371

Comments

@Auron52
Copy link

Auron52 commented Sep 13, 2017

See the discussion at https://groups.google.com/forum/#!topic/emscripten-discuss/zZsG7spmdug for background.

The basic issue is that WASM builds with -s MAIN_MODULE 2 can be unnecessarily large due to extra symbols being exported.

The sample at https://drive.google.com/open?id=0B462aSLeSsPMUFhnNW1iYzhjeHM can be used to reproduce the problem. The zip also includes the output
Build with default MAIN_MODULE=0: 66 KB .js file and 38 KB .wasm file
Build with -s MAIN_MODULE 2: 173 KB .js file and 48 KB .wasm file

Alon Zakai's Comment: "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."

@Shchvova
Copy link

Shchvova commented Apr 4, 2018

This is exactly issue I'm having when trying to use dynamic linking. Just adding -s MAIN_MODULE 2 increases output size dramatically. Are there any updates on this issue?

@tasakm
Copy link

tasakm commented Oct 18, 2018

We too are facing same issue trying to use dynamic linking, WASM binary's size is increasing 3 fold. Is there any workaround to this issue? or any updates the way we can use dynamic linking?

@kripken
Copy link
Member

kripken commented Oct 18, 2018

There have been a bunch of improvements in this area. Try MAIN_MODULE mode 2 on latest incoming, it may be better. However, there are still a bunch of other things that could be done here to improve things, still a work in progress. In particular, see

#7189 (comment)

Would be good if someone had time to investigate that option.

kripken added a commit that referenced this issue Oct 18, 2018
… if your side modules want to call something from the main module, the main module must either export it (normally, on EXPORTED_FUNCTIONS), or you can manually enable EXPORT_ALL yourself. fixes #5586
kripken added a commit that referenced this issue Oct 30, 2018
This is a breaking change, in which we no longer set EXPORT_ALL in MAIN_MODULEs and SIDE_MODULEs. This makes our linking behavior more "standard", and is more future-proof for wasm backend linking.

Fixes #5586, fixes #7189. See more context there.
Beuc pushed a commit to Beuc/emscripten that referenced this issue Nov 17, 2018
This is a breaking change, in which we no longer set EXPORT_ALL in MAIN_MODULEs and SIDE_MODULEs. This makes our linking behavior more "standard", and is more future-proof for wasm backend linking.

Fixes emscripten-core#5586, fixes emscripten-core#7189. See more context there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants