6 ms·

Great, I'll run the benchmark on Firefox. Really excited for this.

azakai 10y ago
Cool. And if you see slowness on more than one browser, please file a bug, it could be something in the toolchain we need to fix (if it's fast in one browser but slow in another, the slow one probably just needs to improve).
- hackcasual 10y ago
  It's 733ms in Firefox, measured from the time doNativeWasm is called until the wasm-instantiate run dependency is removed. Not sure what time should be expected. It's certainly not an order of magnitude faster.
  - azakai 10y ago
    That's not quite measuring the same thing, as it includes the download of the wasm (which will then depend on the webserver, e.g., the simple python one people use for debugging is super-convenient but not that fast). You can force sync compilation (BINARYEN_ASYNC_COMPILATION=0) to make measuring that easier, or measure it in the shell. Also, parsing is separate from optimization. If the browser also optimizes, that takes a lot more than parsing. However, browsers are starting to add baseline JITs for wasm, interpreters, etc., in which case parsing will be the larger factor.
    - hackcasual 10y ago
      Not in this case, I'm preloading the wasm binary blob and then assigning it to the Module object. With the optimization vs. parsing that's a bit opaque and I'd like more control over it. Right now our use case is such that only about 20% of the JS gets used in the first seconds of a users session, so we're paying startup time for code that either will get executed later or not at all.
      - azakai 10y ago
        Oh ok, yeah, if you preload the binary, it's a good measurement (of parsing + optimization). And yeah, it's common that most code is not used early. Browsers are implementing baseline JITs to help there, so they only fully optimize necessary code. I don't think any browser landed that yet though. Another option here is dynamic code loading, if you know some code is only needed later, you can load it yourself (dlopen, etc., which is supported already).

Cool. And if you see slowness on more than one browser, please file a bug, it could be something in the toolchain we need to fix (if it's fast in one browser but slow in another, the slow one probably just needs to improve).

hackcasual 10y ago
It's 733ms in Firefox, measured from the time doNativeWasm is called until the wasm-instantiate run dependency is removed. Not sure what time should be expected. It's certainly not an order of magnitude faster.
- azakai 10y ago
  That's not quite measuring the same thing, as it includes the download of the wasm (which will then depend on the webserver, e.g., the simple python one people use for debugging is super-convenient but not that fast). You can force sync compilation (BINARYEN_ASYNC_COMPILATION=0) to make measuring that easier, or measure it in the shell. Also, parsing is separate from optimization. If the browser also optimizes, that takes a lot more than parsing. However, browsers are starting to add baseline JITs for wasm, interpreters, etc., in which case parsing will be the larger factor.
  - hackcasual 10y ago
    Not in this case, I'm preloading the wasm binary blob and then assigning it to the Module object. With the optimization vs. parsing that's a bit opaque and I'd like more control over it. Right now our use case is such that only about 20% of the JS gets used in the first seconds of a users session, so we're paying startup time for code that either will get executed later or not at all.
    - azakai 10y ago
      Oh ok, yeah, if you preload the binary, it's a good measurement (of parsing + optimization). And yeah, it's common that most code is not used early. Browsers are implementing baseline JITs to help there, so they only fully optimize necessary code. I don't think any browser landed that yet though. Another option here is dynamic code loading, if you know some code is only needed later, you can load it yourself (dlopen, etc., which is supported already).