Dynamic link & MutiThtread Makes Initialization much slower

[oatgnauh]

Version of emscripten/emsdk: emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.54 (48216dc455f2ac2670ec4f8a32f293b62a730080) clang version 19.0.0git (https://github.com/llvm/llvm-project e769fb8699e3fa8e40623764f7713bfc783b0330) Target: wasm32-unknown-emscripten Thread model: posix InstalledDir: /home/compiler/emsdk/upstream/bin

Full link command and output with -v appended:

/home/emsdk/upstream/emscripten/em++  -s EXPORTED_RUNTIME_METHODS='[ "ccall","stringToUTF8","UTF8ToString"]'
-s EXPORTED_FUNCTIONS='["_malloc", "_free"]'
-s WASM=1
-s WASMFS=1
-s ENVIRONMENT=web,worker
-s USE_PTHREADS=1
-s PTHREAD_POOL_DELAY_LOAD=1
-s FULL_ES2=1
-s FULL_ES3=1
-s FORCE_FILESYSTEM=1
-s WARN_ON_UNDEFINED_SYMBOLS=1
-s WASM_MEM_MAX=1073741824
-s TOTAL_MEMORY=1073741824
-s INITIAL_MEMORY=67108864
-s TOTAL_STACK=1048576
-s ALLOW_MEMORY_GROWTH=1
-s FETCH=1
-s RESERVED_FUNCTION_POINTERS=10
-s MODULARIZE=1
-s EXPORT_ES6=1
-s EXPORT_NAME='createModule'
-s TEXTDECODER=0
-frtti
-fPIC
-msimd128 -mbulk-memory
-fwasm-exceptions -sSUPPORT_LONGJMP=wasm
-lopenal
-lembind
-D__linux__=1
-Wl,--no-check-features
-g0 -Oz
-DNDEBUG
-flto
-s OFFSCREENCANVAS_SUPPORT=1
-s OFFSCREENCANVASES_TO_PTHREAD='#canvas' 
-s ASSERTIONS=0
-sSAFE_HEAP=0
--emit-symbol-map
-sWASM_BIGINT
-sERROR_ON_WASM_CHANGES_AFTER_LINK
-sEXCEPTION_STACK_TRACES
-sMAIN_MODULE=2
-sAUTOLOAD_DYLIBS=1
pathto/libdynamic.wasm

for some reason, I have to split the origin main.wasm to main.wasm + side.wasm. And using -s USE_PTHREADS=1 for mutilthread.

createModule

From the phenomenon point of view, the dynamic link version is slower than the non-dynamic link version by 200ms+ in the createModule process. dynamiclink:

normal(non-dynamic link):

in my analyse, these mainly because of LDSO.init(); loadDylibs();, for load-time linking，parsing dynamic lib and exportting symbols map

function createWasm() {
 var info = {
  "env": wasmImports,
  "wasi_snapshot_preview1": wasmImports,
  "GOT.mem": new Proxy(wasmImports, GOTHandler),
  "GOT.func": new Proxy(wasmImports, GOTHandler)
 };
 /** @param {WebAssembly.Module=} module*/ function receiveInstance(instance, module) {
  wasmExports = instance.exports;
  wasmExports = relocateExports(wasmExports, 1024);
  var metadata = getDylinkMetadata(module);
  if (metadata.neededDynlibs) {
   dynamicLibraries = metadata.neededDynlibs.concat(dynamicLibraries);
  }
  mergeLibSymbols(wasmExports, "main");
  LDSO.init();
  loadDylibs();
  registerTLSInit(wasmExports["_emscripten_tls_init"], instance.exports, metadata);
  addOnInit(wasmExports["__wasm_call_ctors"]);
  __RELOC_FUNCS__.push(wasmExports["__wasm_apply_data_relocs"]);
  wasmModule = module;
  removeRunDependency("wasm-instantiate");
  return wasmExports;
 }
 addRunDependency("wasm-instantiate");
 function receiveInstantiationResult(result) {
  receiveInstance(result["instance"], result["module"]);
 }
 if (Module["instantiateWasm"]) {
  try {
   return Module["instantiateWasm"](info, receiveInstance);
  } catch (e) {
   err(`Module.instantiateWasm callback failed with error: ${e}`);
   readyPromiseReject(e);
  }
 }
 instantiateAsync(wasmBinary, wasmBinaryFile, info, receiveInstantiationResult).catch(readyPromiseReject);
 return {};
}

start thread

At the same time, dynamic linking is 200ms+ slower than normal when each thread starts. I guess this is partly because each thread needs to synchronize function symbols from the main thread.

compare to non-dynamic link:

Since these performance degradations are caused by the dynamic link mechanism, it is difficult for users to optimize it. Please give me some feasible suggestions. Thank you.

[oatgnauh]

And I also notice that __wasm_call_ctors cost more time in dynamic link non-dynamic link dynamic link

[sbc100]

While there could be some savings to be had here, dynamic linking does comes at a cost, just like it does on native platforms.