Why after import ASYNCIFY, the project compile so slow

[Perter-Zhang]

Please include the following in your bug report:

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.55 (165133b)
clang version 19.0.0git (https:/github.com/llvm/llvm-project 6c7805d5d186a6d1263f90b8033ad85e2d2633d7)
Target: wasm32-unknown-emscripten
Thread model: posix

Failing command line in full:
NA

Full link command and output with -v appended:

set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_STANDARD 99)

set(CMAKE_BUILD_TYPE, "Debug")

set(CMAKE_CXX_FLAGS "-Wall -Wextra -Wno-comment")
set(CMAKE_CXX_FLAGS_DEBUG "-g")
set(CMAKE_CXX_FLAGS_RELEASE "-O3")

set(CMAKE_C_FLAGS "-Wall -Wextra -Wno-comment")
set(CMAKE_C_FLAGS_DEBUG "-g")
set(CMAKE_C_FLAGS_RELEASE "-O3")
set(CMAKE_EXE_LINKER_FLAGS "-sEXPORTED_FUNCTIONS=_malloc,_free -sALLOW_TABLE_GROWTH -sEXPORTED_RUNTIME_METHODS=dynCall,UTF8ToString,FS -sDYNCALLS --bind -sNO_DISABLE_EXCEPTION_CATCHING -sALLOW_MEMORY_GROWTH -sASYNCIFY --preload-file Layout.xsl --preload-file Code.xml --preload-file Code2.xml --preload-file Resource.rc --preload-file Res")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lidbfs.js")

I am trying to import ASYNCIFY to our poject, the project code is huge
The usage sample code as following:
I try to define a function "WaitModalDialogClose" to listen for the H5 dialog component closing event.
and it will be used in ShowModal function.

But after import ASYNCIFY configuration to project,
in debug version, the compiling and linking are slow. about 30 min in my PC.
Before add ASYNCIFY, the speed about 5 min in my PC.

Does anyone know why compiling and linking can be so slow?
Is there any way to increase the speed?

 EM_ASYNC_JS(INT_PTR, WaitModalDialogClose, (const char* strDialogId, int nLength), {

 	var dialogElementId = UTF8ToString(strDialogId, nLength);
 	dialogElement = document.getElementById(dialogElementId);

 	//create promise to waiting dialog close event
 	var promise = await new Promise((resolve) =>{

 		function handleCloseEvent(event)
 		{
 			dialogElement.removeEventListener("CloseDialog", handleCloseEvent);
 			resolve(event.detail.data);
 		}
 		dialogElement.addEventListener("CloseDialog", handleCloseEvent);
 	}).then((response)=> {
 		return response;
 	});
 	 //return close status
 	return promise;
 });

INT_PTR CDialogContentContextItem::ShowModal()
{
 	return  WaitModalDialogClose(m_strDialogId.c_str(), m_strDialogId.length());
}

[kripken]

This is expected: the Asyncify transform is complex and operates on the entire wasm file, so it is like LTO optimizations. On large projects it can be very slow.

You can make it faster by running Asyncify on less code, see the compiler options that control that:

https://emscripten.org/docs/tools_reference/settings_reference.html#asyncify

And you can use JSPI which does the same as Asyncify but without transforming the wasm (but browser support is in progress).

[Perter-Zhang]

This is expected: the Asyncify transform is complex and operates on the entire wasm file, so it is like LTO optimizations. On large projects it can be very slow.

You can make it faster by running Asyncify on less code, see the compiler options that control that:

https://emscripten.org/docs/tools_reference/settings_reference.html#asyncify

Thank you for your reply,
But i have a question,
I checked the link page, emscripten define series macro to import / add /remove function
(ex: ASYNCIFY_IMPORTS / ASYNCIFY_IGNORE_INDIRECT / ASYNCIFY_REMOVE)

But how can I find what I need to export / add.
I try to add "ASYNCIFY_ADVISE", but it will output lots functions.

And you can use JSPI which does the same as Asyncify but without transforming the wasm (but browser support is in progress).

I tried using JSPI, but the compilation and linking were still slow.

[Perter-Zhang]

I tried using JSPI in another pc, the compilation and linking were fast.

[kripken]

There isn't a perfect way to get the lists for ASYNCIFY_ADD, sadly. Usually it is done by reading the code, by looking at stack traces from errors, etc., but it is error-prone, sadly. That is really what JSPI fixes.