So I've enabled tracing with D8, there I'm seeing 700ms spent by instantiateModule (different machine, different load).
Ran d8 with wasm tracing enabled, which gave me this: Compiling WASM function #0:Jd wasm-decode ok (3.101 ms) wasm-compilation phase 1 ok: 18729 bytes, 3.130 ms decode, 9010 nodes, 28.008 ms pipeline wasm-code-generation ok: 18729 bytes, 0.001 ms code generation Compiling WASM function #1:Id wasm-decode ok (2.101 ms) wasm-compilation phase 1 ok: 17333 bytes, 2.107 ms decode, 10013 nodes, 32.680 ms pipeline wasm-code-generation ok: 17333 bytes, 0.001 ms code generation Compiling WASM function #2:Ld wasm-decode ok (0.989 ms) This was run with only 1 wasm compile task to keep the function and timing for it together in the logs. Decoding time makes up less than 10% of the overall time, with the actual AOT taking over 3 seconds (single threaded). Unfortunately our usecase suffers a bit from an AOT approach, where we have a few big functions that are only called once (better interpreted), a large subset of the functions that are either never called or called some time after page load (better JITted). I've tried enabling the experimental wasm jit, but I'm getting a table size exceeded error. I've put together a visualization (disclosure: I work for Tableau), and it's clear that time is very strongly correlated to # of nodes, no surprise there as its dominated by codegen. http://imgur.com/a/I1zEu On Monday, August 1, 2016 at 9:17:15 AM UTC-7, Charles Vaughn wrote: > > Hi Alon, > > JS time is tricky especially in Chrome. I'll try to strip it down and get > better numbers with D8. > > On Monday, August 1, 2016 at 9:13:21 AM UTC-7, Alon Zakai wrote: >> >> No official benchmarks yet. But you can run the emscripten benchmark >> suite with setting "0" which should be just compile time, almost no >> throughput. >> >> That looks like a valid way to measure wasm compile time. How did you >> measure the JS time? >> >> If possible, links to examples of both, with those measurements, would be >> helpful to see if it's something special in your codebase. >> >> On Fri, Jul 29, 2016 at 2:53 PM, Charles Vaughn <[email protected]> wrote: >> >>> Are there benchmarks for WASM parsing speed? >>> >>> >>> On Friday, July 29, 2016 at 2:39:59 PM UTC-7, Charles Vaughn wrote: >>>> >>>> I used console.time and console.timeEnd around the >>>> wasm.instantiateModule call >>>> >>>> On Friday, July 29, 2016 at 1:32:51 PM UTC-7, Alon Zakai wrote: >>>>> >>>>> I don't know about chrome, but in firefox definitely wasm parsing >>>>> should be massively faster than asm.js - it goes straight from binary to >>>>> the JIT, so JS parsing is completely eliminated. However, if JIT time is >>>>> large enough you might notice this less, as parsing and JITing are done >>>>> together. >>>>> >>>>> How exactly did you measure this in firefox? You should see some web >>>>> console output for compiling asm.js and wasm (which should include >>>>> parsing >>>>> and JIT) that can help. >>>>> >>>>> >>>>> On Fri, Jul 29, 2016 at 8:21 AM, Charles Vaughn <[email protected]> >>>>> wrote: >>>>> >>>>>> I've built my companies internal Emscripten oriented codebase with >>>>>> Binaryen, resulting in an output of ~2MB. Benchmarking time spent to >>>>>> compile the WebAssembly module in Chrome canary shows around 1 second. >>>>>> While its not exactly the same (parse instead of compile), the script >>>>>> streamer thread timing for the equivalent JS (~3.5MB) only takes around >>>>>> 300ms. Using different versions of chrome doesn't seem to impact the >>>>>> timing, and Firefox shows slightly faster, but not better than just JS >>>>>> parse time. >>>>>> >>>>>> Is this expected to improve? >>>>>> >>>>>> -- >>>>>> 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. >>> >> >> -- 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.
