Unexpected increase in javascript file size

[wenhanchong]

Version of emscripten/emsdk: 3.1.41 emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.41 (71634e036d20209a5d81c2b2171e145b44de1e12) clang version 17.0.0 (https://github.com/llvm/llvm-project 88421ea973916e60c34beb26597a5fc33f83dd8f) Target: wasm32-unknown-emscripten Thread model: posix

After upgrading from 3.1.16 to 3.1.41, I noticed a huge increase in the size of my application's javascript file generated by emscripten (1.2MB to 10.8MB). Seems to stem from a change in this PR: https://github.com/emscripten-core/emscripten/pull/18540 where the scope of included functions

settings.DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.extend(strong_imports)

was changed to

settings.DEFAULT_LIBRARY_FUNCS_TO_INCLUDE.extend(sorted(imports))

Some examples of "extra" included functions in js file when using 3.1.41 (names removed):

function __Z10D3E_ABCDI10D3E_EFJHI_() { return wasmImports._Z10D3E_ABCDI10D3E_EFHJI_.apply(null, arguments) } __Z10D3E_ABCDI10D3E_EFHJI_.stub = !0;
function __Z10D3E_ABCDI10D3E_JKLMN_() { return wasmImports._Z10D3E_ABCDI10D3E_JKLMN_.apply(null, arguments) } __Z10D3E_ABCDI10D3E_JKLMN_.stub = !0;
...
var wasmImports = {
  _Z10D3E_ABCDI10D3E_EFJHI_: __Z10D3E_ABCDI10D3E_EFJHI_,
  _Z10D3E_ABCDI10D3E_JKLMN_: __Z10D3E_ABCDI10D3E_JKLMN_,
  ...
  }

Linker flags:

LINK_FLAGS =
-fPIC
-s WASM_BIGINT=1
-fwasm-exceptions
-s MAIN_MODULE=2
-s INCLUDE_FULL_LIBRARY=1
-s AUTOLOAD_DYLIBS=0
-s NO_EXIT_RUNTIME=0
-s INLINING_LIMIT=1
-s FORCE_FILESYSTEM=1
--emit-symbol-map
-s LEGACY_GL_EMULATION=0
-s INITIAL_MEMORY=1000MB
-s ENVIRONMENT=web,worker
-s USE_SDL=0
-s EXPORTED_RUNTIME_METHODS=['allocate','writeArrayToMemory']
-s EXPORT_EXCEPTION_HANDLING_HELPERS=1
-s USE_WEBGL2=1
-s USE_GLFW=3
-s FULL_ES3=1
-s USE_WEBGPU=1
-s WASM=1
-s ALLOW_MEMORY_GROWTH=1
-s EVAL_CTORS=0
WASM1.wasm
WASM2.wasm
WASM3.wasm
-s USE_ICU=1
-flto
-Os
-s GL_TRACK_ERRORS=0

Non-exhaustive list of libraries (names removed):

LINK_LIBRARIES =
--pre-js PREJS.js
--post-js POSTJS.js
-Wl,--whole-archive  LIB1.a
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB2.a
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB3.a
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB4.a
...
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB5.a
-Wl,--no-whole-archive  LIB6.a
LIB7.a
...
LIB8.a
-Wl,--whole-archive  LIB9.a
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB10.a
...
-Wl,--no-whole-archive  -Wl,--whole-archive  LIB11.a
-Wl,--no-whole-archive  LIB12.a
--js-library "JSLIB1.js"
LIB13.a
--js-library "JSLIB2.js"
LIB14.a
LIB15.a
LIB16.a
LIB17.a
...
LIB18.a
LIB2.a
LIB4.a
LIB5.a
LIB19.bc
LIB20.bc
LIB21.bc
LIB22.so
LIB23.a
...
LIB24.a
LIB1.a
LIB3.a
...

[sbc100]

Can you take a look at the specific additions to wasmImports? Can you perhaps share one or two of them?

If now can you run the through c++filt? You might need to remove the leading underscore that gets added in JS?

My guess is that they are all probably weakly defined C++ symbols such as vtables and inline function? Is that right?

[wenhanchong]

Yes they are mainly C++ symbols from our side modules

  _ZTv0_n12_NSt3__218basic_stringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED1Ev: __ZTv0_n12_NSt3__218basic_stringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED1Ev, 
  _ZTv0_n12_NSt3__219basic_ostringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED0Ev: __ZTv0_n12_NSt3__219basic_ostringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED0Ev, 
  _ZTv0_n12_NSt3__219basic_ostringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED1Ev: __ZTv0_n12_NSt3__219basic_ostringstreamIcNS_11char_traitsIcEE18D3E_core_allocatorIcEED1Ev,

[sbc100]

Can you confirm if this is still an issue with the latest versions of emscripten?