There are concerns with the emscripten Godot project that the snapshot will increase bandwidth usage too much. (emscripten support is a separate issue)
For the subset of programs that:
- Wizer unreasonably increases bandwidth usage.
- Want fast page refreshes.
I believe the following would fix the bandwidth problem without undo start delay.
- Project Devs code their WASM's start function for wizer use.
- Project Devs use a small wizer JS wrapper to request the instance of the wasm module.
- Wrapper just passes through to any cached wasm module the following steps created.
- If there isn't a cache, instantiate the downloaded wasm.
- Run the deterministic start function.
- Send a snapshot of the instance's memory to a web worker.
- Run the remaining non-deterministic start function then return the instance like wizer wrapper didn't exist.
- Lazily in the webworker, download wizer compiler.
- Lazily use the snapshot to create a new stripped wasm module and save it into indexeddb.
If even step 6 is too much, then:
- Skip copying the snapshot in step 6 when loading the webpage for the first time.
- Lazily in the web worker create an entirely separate wasm module and start again from Step 4.
There are concerns with the emscripten Godot project that the snapshot will increase bandwidth usage too much. (emscripten support is a separate issue)
For the subset of programs that:
I believe the following would fix the bandwidth problem without undo start delay.
If even step 6 is too much, then: