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 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) 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.. 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 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) 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. -- 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.
