You can gauge current browser behavior by visiting the Zen Garden demo page, which launched with Firefox 52 to showcase new WebAssembly + WebGL 2 support in Epic Games Unreal Engine 4, Emscripten and browsers:
http://mzl.la/webassemblydemo In particular, that page shows timings for cold and warm loads that you can use to estimate how costly loading up a large WebAssembly module currently is, and also how these actions can be performed parallel to each other. On my new 13" MacBook Pro (3.3 GHz Intel Core i7), cold compile time is 8.36 seconds, and a warm startup takes 50 msecs for the Wasm Module, since it is loaded up from IndexedDB directly. At that point, like you can see there, the warm startup time is dominated by other things rather than WebAssembly. 2017-03-20 22:40 GMT+02:00 'Derek Schuff' via emscripten-discuss < [email protected]>: > > > On Thu, Mar 16, 2017 at 1:41 PM <[email protected]> wrote: > >> 1) I observed that Chrome Canary is faster at webassembly startup by >> about 1 second as compared to mainline chrome released. >> Similar observation for FF (gap is less there though) - FF webassembly >> startup is slower than asm.js but nightly has caught up back. >> Is it because some extra VM improvement for WASM has been added in canary >> and nightly which will land mainline soon? (maybe like using multicore for >> parallel parsing or running baseline compiler if module is not already >> compiled >> > > This is certainly true for Chrome; there are multiple improvements on tip > of tree beyond what's released in 57. It wouldn't surprise me if it were > the same for FF; it's still pretty early days. > > > >> Or are mainline browsers supposed to do some extra validations ? >> >> 2) I am currently reading hacks articles by Lin Clark and Alon regarding >> what makes webassembly fast and they are pretty cool. I am getting greedy >> by reading Alon's latest article. >> >> What can a "wasm web developer" do to make the performance even faster >> (except storing in indexeddb ) which would across devices like mobiles and >> tablets across all browsers (Edge, Chrome FF and hopefully Safari later) ? >> > > >> Will the following help? >> >> a)(startup time on second launch) I believe loading cached code(second >> time) from indexeddb cannot be made faster by web developer (since the code >> is already compiled - it would not be decoded and validated again but just >> executed in sandbox) >> > > You are correct, although there's no guarantee. I'm not sure how far along > the browsers are with that but it should eventually be the case. > > >> >> b) (startup time on first launch) And First time launch - Avoiding "VM >> fully optimizing the code" would be done by browsers and not web developer >> I believe. Maybe web developer could use empterpretor white list or plain >> JS on first launch and then fallback to fast wasm code when compilation is >> done at idle in other cores and store the code in indexeddb for future >> launches. But FF two compiler model (when it is out) will make it >> unnecessary.. >> > > The browsers are also trying to optimize first launch time. Most likely > this means a fast baseline compiler that runs on the first call and then > tiering up to an optimizing compiler. Obviously if you have a plan JS > implementation of the same functionality as wasm you could use that, but a) > many people won't, and b) hopefully with the wasm baseline JIT, it wouldn't > be much faster. > > >> >> c) (startup time/general JS execution) Reduce memory footprints (in case >> it helps on low RAM mobile devices) by splitting code in modules (in >> indexeddb) and loading only required modules to memory >> > > In general, reducing the size of linear memory is likely to be helpful. > asm.js imposes a significant cost if you enable memory growth, but wasm > does not. So if you can come up with some reasonable guess about memory > size that will cover, say 80% of your cases, but can't guarantee that it > will never be more, you can start with the small estimate and enable > growth. It also might depend on how much you care about 32-bit devices. > > >> >> d) (general JS execution) Garbage collection cost (from Lin's diagram) >> appear to be zero. If that is the case, we may be able to remove plain JS >> code from the wasm webworker totally - this would ensure that GC task does >> not run at all (even for few milliseconds) in webworker - and main tasks >> would get more cpu (but maybe GC would run at idle time only - when >> webworker does a context switch from WASM mode to plain JS mode to >> communicate with main UI thread) >> > > wasm code doesn't have heap objects, but there is still the JS<->wasm > interface in the engine and the emscripten module code itself. We're a ways > from being able to remove that from threads entirely. > > >> >> e) (general performance) giving very less value of TOTAL_MEMORY (for low >> memory footprints on mobile to get better performance) and growing the >> memory automatically on need basis(since memory growth incurs zero penalty >> in WASM >> Avoiding exceptions and minimizing cross call between JS and WASM is >> clear. >> > > see the answer to c) above. Also, yes, exceptions still have a large cost > in emscripten (eventually we hope to add native support in wasm for that), > and JS<->wasm calls still have the same cost as JS<->asm.js calls. > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
