Summary: | Performance test IndexedDB/large-binary-keys.html creates a DB of more than 6GB and takes more than 10 minutes to run | ||
---|---|---|---|
Product: | WebKit | Reporter: | Carlos Alberto Lopez Perez <clopez> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | achristensen, beidson, bugs-noreply, cgarcia, lforschler, ossy, rniwa |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 165567 |
Description
Carlos Alberto Lopez Perez
2017-01-30 17:07:01 PST
I think it's worth testing (It's provided huge benefit already) (In reply to comment #1) > I think it's worth testing (It's provided huge benefit already) On the GTK+ perf bot this test is taking ~1620 seconds, which is beyond the 1200 global timeout for any step to be working without any output. So it causes the whole step to abort. I will have to skip it on the GTK+ Perf bot until the test is changed to run faster, or some optimization is done on the WebKit/WebKitGTK+ code that makes it run faster. Note also that I'm also proposing a patch on bug 167626 to bring back the 600 timeout value for any perf test. I don't think a unique test should take more than this (10 minutes) to run. We are already having 3+ hours long perf test steps, and if individual tests are allowed to run for more than 10 minutes we will be soon having much longer perf test steps. On the Apple port this test takes ~17 minutes https://build.webkit.org/builders/Apple%20El%20Capitan%20Release%20WK2%20%28Perf%29/builds/4138/steps/perf-test/logs/stdio Running IndexedDB/large-binary-keys.html (78 of 162) RESULT IndexedDB: large-binary-keys: Time= 12710.29875 ms median= 12767.6 ms, stdev= 192.085687956 ms, min= 12049.8 ms, max= 12873.7 ms RESULT IndexedDB: large-binary-keys: JSHeap= 690339155.65 bytes median= 663655063.0 bytes, stdev= 248329564.206 bytes, min= 248397774.0 bytes, max= 1206834295.0 bytes RESULT IndexedDB: large-binary-keys: Malloc= 847334707.2 bytes median= 872071168.0 bytes, stdev= 258591471.735 bytes, min= 369184768.0 bytes, max= 1255882752.0 bytes Finished: 1048.817416 s But, on the EFL port however this test only takes 5 minutes! Running IndexedDB/large-binary-keys.html (78 of 162) RESULT IndexedDB: large-binary-keys: Time= 6281.455 ms median= 6316.0 ms, stdev= 255.338836634 ms, min= 5291.3 ms, max= 6786.8 ms RESULT IndexedDB: large-binary-keys: JSHeap= 469837447.4 bytes median= 416166533.0 bytes, stdev= 153900199.697 bytes, min= 235825501.0 bytes, max= 835616357.0 bytes RESULT IndexedDB: large-binary-keys: Malloc= 896776601.6 bytes median= 873631744.0 bytes, stdev= 193327106.186 bytes, min= 486801408.0 bytes, max= 1116913664.0 bytes Finished: 531.608296 s https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/11181/steps/perf-test/logs/stdio I wonder what can explain such massive performance improvement on that port? This test was skipped for the GTK+ Perf bot in https://trac.webkit.org/changeset/211430/trunk/PerformanceTests/Skipped |