3 ms·

Using Emscripten (with embind) 1.37.3 it takes slightly over 1 second to initialize a 2.7mb wasm file. The JS version shows slightly under 300ms for parse time,

Using Emscripten (with embind) 1.37.3 it takes slightly over 1 second to initialize a 2.7mb wasm file. The JS version shows slightly under 300ms for parse time, obviously not the same as the full WASM pass, but it does significantly delay initial page load. The positive side is what took 250ms to run with cold JS (nothing JIT compiled) and 35ms after a few runs takes just 5ms the first time in WASM. This is on Chrome Canary on Windows. Is there anything I'm missing to speed this up?

jsheard 10y ago
Have you tried compiling your project with the -Os flag instead of -O2 or -O3, so the optimizer prefers to generate smaller code? Performance will be slightly worse but a smaller wasm binary means less for the browser to deal with on initialization.
- hackcasual 10y ago
  Yes, it's compiled in Oz.
azakai 10y ago
Startup time is a known issue specifically on Chrome. It's being focused on, so improvements are expected.
- hackcasual 10y ago
  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).

jsheard 10y ago

Have you tried compiling your project with the -Os flag instead of -O2 or -O3, so the optimizer prefers to generate smaller code? Performance will be slightly worse but a smaller wasm binary means less for the browser to deal with on initialization.

hackcasual 10y ago
Yes, it's compiled in Oz.

azakai 10y ago

Startup time is a known issue specifically on Chrome. It's being focused on, so improvements are expected.

hackcasual 10y ago
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).