Issue metadata
Sign in to add a comment
|
indexedDB put performance regression |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3287.0 Safari/537.36 Steps to reproduce the problem: 1. visit https://files.unity3d.com/alexsuvorov/test/chrome-wasm-caching/ using Chromium 522320 2. visit https://files.unity3d.com/alexsuvorov/test/chrome-wasm-caching/ using Chromium 522328 in the log, you will find text like: Successfully cached wasm module using out-of-line key in ... ms you will see that 522328 takes much longer. What is the expected behavior? What went wrong? It seems Chromium 522328 introduced a serious performance regression in IndexedDB put. Note that this is using out-of-line keys. Did this work before? Yes Chromium 522320 Chrome version: 65.0.3287.0 Channel: n/a OS Version: 10.0 Flash Version:
,
Dec 13 2017
Assuming the versions given are Cr-Commit-Position numbers, the commit logs appears to be: https://chromium.googlesource.com/chromium/src/+log/c85564acc3bb9ec889c632f00be19fb782f53bbc..4226212ea2e9a4c1293203d09d6e4ae4ecaeecd8 I don't see any IndexedDB-related changes there. The only interesting bit I see is a V8 roll: https://crrev.com/c/812215 I'll check out the relevant versions and try to repro.
,
Dec 14 2017
Reproduced on Windows 522320 / c85564acc3bb9ec889c632f00be19fb782f53bbc [WasmCache] Successfully cached wasm module using out-of-line key in 319 ms 522328 / 4226212ea2e9a4c1293203d09d6e4ae4ecaeecd8 [WasmCache] Successfully cached wasm module using out-of-line key in 22345 ms
,
Dec 14 2017
The regression appears to have been introduced by the V8 roll in https://crrev.com/c/812215 522326 / 0021fbb093860cf5cb72b854c99216e38d5e456e / https://crrev.com/c/812215 [WasmCache] Successfully cached wasm module using out-of-line key in 21996 ms 522325 / dbc5706be665e9c4b78e660ce08dba3b50f3ad6d [WasmCache] Successfully cached wasm module using out-of-line key in 327 ms
,
Dec 14 2017
Thanks for narrowing that down. I'll follow up on the v8 side.
,
Dec 21 2017
,
Dec 22 2017
It appears https://chromium.googlesource.com/v8/v8/+/02d201bfdd18f1292146dd32bcca911c3465a991 is the culprit. The issue may be reproed in tip of tree: chrome --enable-features="WebAssembly" chrome --enable-features="WebAssembly" --js-flags="--no-write-protect-code-memory" Note that enabling jit off the heap also solves this. In fact, it appears to halve the serialization time. chrome --enable-features="WebAssembly" --js-flags="--wasm-jit-to-native"
,
Jan 16
(6 days ago)
This should be fixed, as we fell back to not write-protecting code pages for WASM due to performance regressions.
,
Jan 16
(6 days ago)
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mtrofin@chromium.org
, Dec 13 2017Owner: pwnall@chromium.org