Victor Adossi (Jan 08 2025 at 18:21): Victor Adossi (Jan 08 2025 at 18:21):Hey all, did some exploration after the meeting today and it looks like even with -O0 and --asyncify the actual wasm-opt asyncify pass takes ~285 seconds.
Here's some of the debug output:
STDERR: reading...
reading binary from /tmp/XXXXXXV5Q0g2/in.wasm
Loading '/tmp/XXXXXXV5Q0g2/in.wasm'...
warning: unknown name subsection with id 3 at 11208202
running passes...
[PassRunner] running passes
[PassRunner] running pass: asyncify... 285.411 seconds.
[PassRunner] (validating)
[PassRunner] passes took 285.411 seconds.
[PassRunner] (final validation)
writing...
writing binary to /tmp/XXXXXXV5Q0g2/out.wasm
Opening '/tmp/XXXXXXV5Q0g2/out.wasm'
I think there might not be a way to get past this for asyncify itself, so unless someone has some insight into some other flags I should be using, we may have to do some combination of the following:
Committing just one more binary (and possibly writing it in some other language like Rust) which has all the tests we'd like to do might not be a terrible solution after all, as opposed to using the ability to dynamically build the JS components during the tests.
Guy Bedford (Jan 08 2025 at 21:14):An optimized approach might be to splice in asyncify compatible functions in the ComponentizeJS splicer itself
Guy Bedford (Jan 08 2025 at 21:14):ie having ComponentizeJS have an "asyncify aware" output mode
Victor Adossi (Jan 09 2025 at 06:52):Ah thanks that's a good idea -- this is quickly becoming a separate effort worth doing, but in that direction one thing I'll do just to verify that pre-asyncify'd starlingmonkey works properly, then start looking at the slicer.
Will put this on the back burner though for now!
Last updated: Jan 24 2025 at 00:11 UTC