It seems that what is slow here is the `--asyncify` pass in wasm-opt.
 IIUC that pass will be slower or faster depending on how much of your
program need to be asyncified.

If you are using embind with asyncify I don't think you can avoid the need
to asyncify calls to _emval_await so I'm not sure what you can do to try to
speed up that pass.  Others may have some tricks they know about?

As an alternative to asyncify we also have `-sJSPI` which doesn't require
this pass, but is also not yet available in stable browsers.

cheers,
sam

On Sun, Jul 7, 2024 at 11:59 PM themixup <h2o...@gmail.com> wrote:

> Thank you. sam.
> I changed the options as instructed and did the profiling. After checking
> the results, I identified sections where time was being consumed.
> Could *._emval_await be affecting this? When compared to other projects,
> there is a difference in *._emval_await.
>
> profile.html
> {
>     "pid": 110007,
>     "subprocessPid": 110007,
>     "op": "spawn",
>     "targetPid": 110114,
>     "time": *1720413197.1*,
>     "cmdLine": [
>       "/home/test/dev/emsdk/upstream/bin/wasm-opt",
>       "--strip-target-features",
>       "--post-emscripten",
>       "-O3",
>       "--low-memory-unused",
>       "--asyncify",
>       "--pass-arg=asyncify-asserts",
>       "--pass-arg=asyncify-imports@env.invoke_
> *,env.__asyncjs__*,*.fd_sync,*.emscripten_promise_await,*.emscripten_idb_load,*.emscripten_idb_store,*.emscripten_idb_delete,*.emscripten_idb_exists,*.emscripten_idb_clear,*.emscripten_idb_load_blob,*.emscripten_idb_store_blob,*.emscripten_sleep,*.emscripten_wget_data,*.emscripten_scan_registers,*.emscripten_lazy_load_code,*._load_secondary_module,*.emscripten_fiber_swap,*.SDL_Delay,
> **._emval_await*",
>       "--zero-filled-memory",
>       "--pass-arg=directize-initial-contents-immutable",
>       "test.wasm",
>       "-o",
>       "test.wasm",
>       "--mvp-features",
>       "--enable-mutable-globals",
>       "--enable-sign-ext"
>     ]
>   },
>   {
>     "pid": 110007,
>     "subprocessPid": 110007,
>     "op": "*wait*",
>     "targetPid": 110114,
>     "time": *1720413197.1*
>   },
>   {
>     "pid": 110007,
>     "subprocessPid": 110007,
>     "op": "*finish*",
>     "targetPid": 110114,
>     "time": *1720416042.543*,
>     "returncode": 0
>   },
>
> 2024년 7월 6일 토요일 오전 1시 36분 27초 UTC+9에 s...@google.com님이 작성:
>
>> You can run your link command with `EMPROFILE=2` set in the environment
>> and emscripten will print a breakdown of the various link steps.
>>
>> If you want even more details you can use `EMPROFILE=1` to produce a
>> trace that can be rendered as html.
>>
>> See https://emscripten.org/docs/optimizing/Profiling-Toolchain.html
>>
>> cheers,
>> sam
>>
>> On Fri, Jul 5, 2024 at 7:44 AM themixup <h2o...@gmail.com> wrote:
>>
>>> During the Reelase build process, compilation is quick but optimization
>>> takes a long time. But  Debug type is fast.
>>> How can I identify which parts are taking the most time during
>>> optimization?
>>>
>>> * emcmake cmake -S ../ -DCMAKE_BUILD_TYPE=Release
>>> * build time : 30minutes more...
>>>
>>> * cmakelist build link option
>>> "SHELL:-s EXPORTED_FUNCTIONS='[\"_malloc\", \"_free\"]'"
>>> "SHELL:-s EXPORTED_RUNTIME_METHODS='[\"ccall\", \"cwrap\", \"FS\",
>>> \"stringToUTF16\", \"UTF8ToString\", \"lengthBytesUTF8\",
>>> \"allocateUTF8\"]'"
>>> "SHELL:-s NO_EXIT_RUNTIME=1"
>>> "SHELL:-s ELIMINATE_DUPLICATE_FUNCTIONS=1"
>>> "SHELL:-s ERROR_ON_UNDEFINED_SYMBOLS=1"
>>> "SHELL:-s ASSERTIONS=2"
>>> "SHELL:-s FORCE_FILESYSTEM=1"
>>> "SHELL:-s MAX_WEBGL_VERSION=2"
>>> "SHELL:-s WASM=1"
>>> "SHELL:-v"
>>> "SHELL:--bind"
>>> "SHELL:-s ALLOW_MEMORY_GROWTH=1"
>>> "SHELL:-s ALLOW_TABLE_GROWTH=1"
>>> "SHELL:-s TOTAL_MEMORY=1024MB"
>>> "SHELL:-s STACK_SIZE=5MB"
>>>
>>> *  my setting
>>> cpu :i7-13700
>>> ram :32GB
>>> ssd :500GB
>>> emsdk : 3.1.53
>>>
>>>
>>> --
>>> 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-disc...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/emscripten-discuss/1b28b3d5-fdc3-432d-bf07-0010570cb2acn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/emscripten-discuss/1b28b3d5-fdc3-432d-bf07-0010570cb2acn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/f6b39d3a-6d4c-425d-83f7-561f891dcf3dn%40googlegroups.com
> <https://groups.google.com/d/msgid/emscripten-discuss/f6b39d3a-6d4c-425d-83f7-561f891dcf3dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va293xnbBEz%2BZ_Dx5%2BS0K%2BuNK9Ky508AMzr%3D9orQH1FzNFw%40mail.gmail.com.

Reply via email to