Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Way to use precompiled wasm object? #8279

Closed
saschanaz opened this issue Mar 10, 2019 · 8 comments
Closed

Way to use precompiled wasm object? #8279

saschanaz opened this issue Mar 10, 2019 · 8 comments
Labels

Comments

@saschanaz
Copy link
Collaborator

saschanaz commented Mar 10, 2019

It seems Node.js doesn't cache the compiled wasm binary by default (saschanaz/flif-wasm#8, nodejs/node#18265).

So I want to use v8.serialize and v8.deserialize to cache it myself and pass it to emscripten JavaScript wrapper. Is it possible now?

Short deserialization example: https://runkit.com/saschanaz/5c84667c6e2ea0001222a59f

@sbc100
Copy link
Collaborator

sbc100 commented Mar 11, 2019

I'm don't know a lot about node but wouldn't it be nicer to have this caching happen transparently? i.e. have it happen inside of node or v8? Perhaps by intercepting calls to new WebAssembly.Module in some way?

@saschanaz
Copy link
Collaborator Author

@sbc100 Agree, but not an option in current versions.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 11, 2019

I guess what I'm saying is that this bug should probably be filed against node.js so that it can benefit all wasm node users, not just emscripten users.

@sbc100
Copy link
Collaborator

sbc100 commented Mar 11, 2019

Oh I see you already referenced the upstream bug. Sorry for not reading that correctly.

@saschanaz
Copy link
Collaborator Author

saschanaz commented Mar 12, 2019

That bug is about deserializing a manually cached binary.

It seems the browser devs want to do it in HTTP cache level rather than to do some magic in the Module constructor, which won't be helpful when the wasm file is in local.

kripken added a commit that referenced this issue Nov 28, 2019
kripken added a commit that referenced this issue Dec 13, 2019
See #8279 - this uses the Node.js v8 API to use the same mechanism
that Chrome uses to cache compiled code and make second and
later runs much faster.

In the browser this is automatic, while here we must do it manually.
Otherwise though it's the same.

The only tricky thing is that this adds the V8 version to the cache
file, as the file is not compatible with another version, and it may
silently fail (throw away the compiled code, and recompile).
@stale
Copy link

stale bot commented Mar 11, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Mar 11, 2020
@kripken
Copy link
Member

kripken commented Mar 11, 2020

This was implemented as an option in #9948

@kripken kripken closed this as completed Mar 11, 2020
@saschanaz
Copy link
Collaborator Author

Specifically it's NODE_CODE_CACHING=1 👍

belraquib pushed a commit to belraquib/emscripten that referenced this issue Dec 23, 2020
…#9948)

See emscripten-core#8279 - this uses the Node.js v8 API to use the same mechanism
that Chrome uses to cache compiled code and make second and
later runs much faster.

In the browser this is automatic, while here we must do it manually.
Otherwise though it's the same.

The only tricky thing is that this adds the V8 version to the cache
file, as the file is not compatible with another version, and it may
silently fail (throw away the compiled code, and recompile).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants