You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current typescript-based implementation assumes that when passing a literal to a constructor like this:
newFoo(`some string literal`)
the string literal can be garbage-collected since it's never used again in code. This means that we can convert the base64-encoded version to a smaller Uint8Array representation. We may additionally choose to keep that representation compressed, or decompress it. But because the original literal is GC'd, we don't have to care about doubling memory usage.
But, does the WASM runtime allow for that? If a literal is encoded in the WASM file, and the WASM file is loaded into a state machine, it's just going to stay in memory for the entire lifetime of the WASM module, right?
That may still be fine if we load & keep compressed bytes directly from the module. But we'd also want to check on any inefficiencies that passing those bytes into JS might introduce.
Deno 2.1 adds even better support for loading WASM modules.
I bet storing binary data inside of a WASM file might be more space-efficient than storing it as base64 data inside of a
.ts
file.Would be fun to implement a WASM option to compare the two.
The text was updated successfully, but these errors were encountered: