Hi Derek, all,
What is the WASM performance improvements roadmap for chrome canary?

As per my observations:

(1) Windows -  latest Chrome canary is now fast (good throughput after 1 
second of AOT - 20 to 50% slower than FF). It appears to be supporting 
indexeddb but there is no difference in startup performance Regardless of 
whether indexeddb is used or not, the AOT time is always 1 sec (time taken 
from first line of prejs to first line of  main). If indexeddb is used, 
shouldn't AOT time be 100 sec instead of 1+ sec ?  Once in a quarter, when 
a major update of browser with breaking change is released, it would be 
fair to expect to AOT hit of 1 sec.
Is there any way to hint chrome to avoid re-AOT of indexeddb code(whatever 
it is - parsing, validation) ? There should not be any security issue(SOP 
is still followed for indexeddb and no poisioning should be possible in 
threat model.

(2) Mac - Chrome canary on Mac still does not support indexeddb. And 
performance is still at earlir older levels (about 300% slower than 
windows). This performance is at same level  as what was on in initial wasm 
release build of chrome on windows.
This leads me to believe that all new webassembly features (including 
performance improvements) are disabled on mac (or are win only) despite the 
pipeline being same on both platforms. Is it true ?

(3) Android - chrome canary on Android is slow ( 250% slower than firefox 
nightly on same device). chrome 58 crash on android(wasm) was fixed in 
chrome 59 - wasm changes are happening on chrome android but something is 
missing looking at PERF side. 
Does it uses 8 cores (when cores are not sleeping) for AOT ?  And are there 
any techniques in chrome or application code to speed up the throughput 
(yes throughput is much slower than expected). In JS benchmarks (old-octane 
and jetstream) chrome and FF are at par mostly on android. Do these 
observations correlate with WASM versions of embenchen and massive 
(micro-benchmark or macro-benchmark apps) on android phone ? Is this 
slowness due to RAM/android resource management or chrome optimization on 
android ?
I am testing under ideal conditions (and repeating the tests).


Thanks

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

Reply via email to