Provide a way to detect asyncified exports #2322
Comments
|
(I'm working on this and have a PoC implementation locally) |
RReverser
added a commit
to RReverser/binaryen
that referenced
this issue
Sep 3, 2019
Names of all the asyncified export functions are now added as data of custom "asyncify" sections. This allows to detect them in a JS wrapper and wrap into async JS functions only if necessary. We could come up with a more condensed representation that doesn't duplicate export function names or name of "asyncify" section itself, but this would add unnecessary complexity to implementation with little benefit after Gzip / Brotli, which already take care of duplicated strings quite well. Fixes WebAssembly#2322.
RReverser
added a commit
to RReverser/binaryen
that referenced
this issue
Sep 3, 2019
Names of all the asyncified export functions are now added as data of custom "asyncify" sections. This allows to detect them in a JS wrapper and wrap into async JS functions only if necessary. We could come up with a more condensed representation that doesn't duplicate export function names or name of "asyncify" section itself, but this would add unnecessary complexity to implementation with little benefit after Gzip / Brotli, which already take care of duplicated strings quite well. Fixes WebAssembly#2322.
RReverser
added a commit
to RReverser/binaryen
that referenced
this issue
Sep 3, 2019
Names of all the asyncified export functions are now added as data of custom "asyncify" sections. This allows to detect them in a JS wrapper and wrap into async JS functions only if necessary. We could come up with a more condensed representation that doesn't duplicate export function names or name of "asyncify" section itself, but this would add unnecessary complexity to implementation with little benefit after Gzip / Brotli, which already take care of duplicated strings quite well. Fixes WebAssembly#2322.
RReverser
added a commit
to RReverser/binaryen
that referenced
this issue
Sep 4, 2019
Names of all the asyncified export functions are now added as data of custom "asyncify" sections. This allows to detect them in a JS wrapper and wrap into async JS functions only if necessary. We could come up with a more condensed representation that doesn't duplicate export function names or name of "asyncify" section itself, but this would add unnecessary complexity to implementation with little benefit after Gzip / Brotli, which already take care of duplicated strings quite well. Fixes WebAssembly#2322.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, Asyncify pass transforms only functions that call into potentially asynchronous imports (directly or indirectly) and leaves others untouched.
However, from the JavaScript wrapper side, it's impossible to know which exports ended up being asyncified and which not, and so all exported functions end up being transformed into
asyncones even if it's unnecessary.In order to improve efficiency and provide an async API only for exports that actually require it, Asyncify pass should somehow mark the transformed exports.
There are two potential ways to go about this: 1) add custom prefix or suffix to export names which would be detected as a marker and stripped by the JS wrapper or 2) add a custom section(s?) listing all such export names that could be read by JS wrapper using
WebAssembly.customSections('asyncify').The text was updated successfully, but these errors were encountered: