Webassembly Startup Time too high

[Gaurav Dewan]

I have noticed that webassembly application startup time is too slow as compared to ASM.JS application(even when the whole wasm file is loaded from cache. The slow startup is not due to network download.).

Once the webpage has loaded fully then the webpage interaction with user is very fast. But the primary concern is slow startup(1.5 times slower than ASM.js).

Both chrome canary and firefox nightly exhibit this behavior.

Is it AsDesign or any 3x improvement planned in this area from browser side?

Do browser validate Webassembly and take large time in the process or is there any option to  ask browser to speed up?

[Floh]

What is your .wasm size? I found the startup time for my (small-ish) demos is very fast for Firefox, but much slower for Chrome (although this is expected to improve).

Also, one thing I stumbled over was that .wasm files might not be compressed by the web server (for instance, github pages compressed .js files, but not .wasm files, I renamed to .wasm file to .wasm.txt to workaround the issue). You should check in the browser devtools whether the initial download is compressed and whether this might explain the time difference. The compressed size of the wasm file should be slightly smaller than the compressed asm.js size.

-Floh.

[Floh]

Oh, sorry, I should have read your post more carefully, you already said that it is not the download that's slow.

So... I noticed slow startup behaviour in Chrome, but not in Firefox. However my demos are small, just a couple hundred kilobytes.

[Alon Zakai]

There are a few possible issues here. But overall the answer is: things will get better, wasm perf now is not near the target.

First, asm.js in firefox has code caching. Wasm does not have that, intentionally, as there are plans to add a better and standardized way to cache. But right now it means slower warm loads in firefox.

Second, chrome on asm.js and wasm does more AOT style compilation, which is slower than the lazy approach it would use on normal JS, and is still being optimized. In particular, last I checked it was not compiling in parallel yet. When that arrives it should be a big speedup, like it was for firefox.

Another possibility is some startup changes in wasm vs asm.js code on the emscripten side. For example we need to download the wasm binary before loading the rest of the JS. If the rest of the JS is big, that might be noticeable. We should optimize that eventually. Using the browser perf tools might show if this is the issue (you'll see a pause before compiling the wasm).

Aside from those factors, if you still see wasm 1.5x slower than asm.js, then that is surprising and not a known issue in either browser - it should be faster as a binary is being loaded, no JS is being parsed. Worth creating a testcase and filing an issue.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JF Bastien]

The Chrome startup time issue is know, and will be fixed before wasm is stable.

On Tue, Apr 26, 2016 at 4:07 AM, Gaurav Dewan <gauravd...@gmail.com> wrote:

[Gaurav Dewan]

Thanks for comprehensive explanation. I now reckon that we will see browser improvements in startup time.

 

 I will look at the timing data of webassembly based webpage startup to verify there is no other surprise angle here.The main thread cannot do much more than showing progressbar until the cpu/memory intensive single wasm file is downloaded fully and loaded into memory.  Single WASM cannot in general be broken down into multiple WASM files(not many portable C++ projects would be designed to look at on-demand dynamic loading as means of increasing startup performance). I guess, the whole WASM file needs to be downloaded into Module.wasm variable and instantiateModuled  before "any" WASM function can be invoked (not read the mvp specs). 

 

BTW, is there any forum(w3c working group or webassembly specific forums) or bug tracker using which I can remain updated on browser webassembly progress ?

[JF Bastien]

On Thu, Apr 28, 2016 at 10:58 AM, Gaurav Dewan <gauravd...@gmail.com> wrote:

Thanks for comprehensive explanation. I now reckon that we will see browser improvements in startup time.

 

 I will look at the timing data of webassembly based webpage startup to verify there is no other surprise angle here.The main thread cannot do much more than showing progressbar until the cpu/memory intensive single wasm file is downloaded fully and loaded into memory.  Single WASM cannot in general be broken down into multiple WASM files(not many portable C++ projects would be designed to look at on-demand dynamic loading as means of increasing startup performance). I guess, the whole WASM file needs to be downloaded into Module.wasm variable and instantiateModuled  before "any" WASM function can be invoked (not read the mvp specs). 

We're planning to support full dynamic linking for wasm, at a minimum we'll support memory sharing and *direct* function sharing between .wasm modules in MVP. We haven't updated the design repo with details yet, will do soon. That won't be automatic though: you'll need to build your C++ project into separate modules.

BTW, is there any forum(w3c working group or webassembly specific forums) or bug tracker using which I can remain updated on browser webassembly progress ?

webassembly.github.io has everything. The design and spec repos are where more of the action happens.