See https://github.com/WebKit/JetStream/pull/167
- Collect and report subTimes like subScores
- Only show times if the global .details CSS class is set (the default view is unaffected)
- Also use .details for displaying displayCategoryScores
- Change uiFriendlyDuration to only report 2 significant digits
- Add Benchmark.prototype.wallTime accessor and report that as well
- Use # as unit symbol for console printing
Change-Id: Ibc603b29c516060823c39c738069466cff57170a
Reviewed-on: https://chromium-review.googlesource.com/c/external/github.com/WebKit/JetStream/+/6976231
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
3c31693 Simplify formatting (#79)
0633ab2 Merge pull request #90 from kmiller68/fix-prepareForNextIteration-async-benchmark
5d0005e Move prepareForNextIteration call from Benchmark's runnerCode to preIterationCode
df99e62 Merge pull request #74 from kmiller68/preload-blobs-wasm
510e017 Move the loading code to shared prerunCode helpers
bcfccc3 Fix between benchmark network requests for Dart-flute's JS Module. In that process I also had to change how 8bitbench loads the rom it's going to use.
8869c79 Move blob fetching to runnerCode since it needs to do an async operation to get the blob as an array buffer in modern browsers.
a6bd526 Pass the blob URL for preloads in WasmEMCCBenchmark.
9163dcb Merge pull request #76 from kmiller68/zlib-check-_compressFile-to-setupModule
c3773cd Revert #78 as it broke JetStream3 on web page
8204b57 Remove custom run methods #78
Change-Id: I27a5856ea23e52fa298c2751d2e110460f90e73a
Reviewed-on: https://chromium-review.googlesource.com/c/external/github.com/WebKit/JetStream/+/6737289
Reviewed-by: Daniel Lehmann <dlehmann@chromium.org>
The usual changes: use `WasmEMCCBenchmark` class for running, rebuild and add build script, use iteration count that makes the Wall time not too high (<2s)
In this case, we spend a bit more time in the top-tier than before. However, that line item earlier ran a single <50ms iteration, and compiled for ~2ms, so I would argue it was very prone to noise, and it's good that we run it for longer.
Same steps as for the other Wasm line items:
- Move files to subdirectory.
- Rebuild with up-to-date Emscripten.
- Reduce single iteration time, so that we can run multiple iterations (a single iteration before took ~300ms, now ~30ms).
- Checked that we spend roughly the same amount of CPU samples in the top-tier and that overall profiles look similar.
This is another asm.js benchmark that we missed from before. Like float-mm.c, we don't
think asm.js has enough in the wild usage to justify benchmarking.
This is another asm.js benchmark that we missed from before. Like float-mm.c, we don't
think asm.js has enough in the wild usage to justify benchmarking.
...which can help to profile only code which is actually measured, not the setup and driver.
Also some drive-by fixes: Add sqlite3-wasm to `wasm-cli.js` runner and fix typo.
Build with the same options (-O2, Emscripten MODULARIZE, etc.) as TSF-wasm before.
Use the WasmEMCCBenchmark class introduced earlier.
Since we want to run multiple iterations (for first, average, worst scoring), change to small workload size.
Each individual iteration still runs >20ms, which we agreed on in the last sync.
Drive-by fixes:
The WasmEMCCBenchmark setup code needs to make sure we don't automatically run main() after setupModule().
The TSF-wasm build script uses `set -o pipefail`, which is a bash option, hence change shebang line.
Add Wall time output also for WasmEMCCBenchmark and WasmLegacyBenchmark.
Since this test is relatively slow per iteration I reduced the iteration counts to:
non-simd: 15 iterations with worst 2.
simd: 80 iterations with worst 4 (default).
Also, I moved all the benchmark files to a tfjs directory to help organize the wasm directory a bit.
