Issue metadata
Sign in to add a comment
|
12.3% regression in storage.indexeddb_endure at 419045:419105 |
||||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Sep 20 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9000984730034867264
,
Sep 20 2016
=== Auto-CCing suspected CL author jbauman@chromium.org === Hi jbauman@chromium.org, the bisect results pointed to your CL below as possibly causing a regression. Please have a look at this info and see whether your CL be related. ===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : Enable GPU rasterization on Windows Intel Broadwell and later GPUs. Author : jbauman Commit description: List from https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_pciids.h BUG= 646135 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2337863002 Cr-Commit-Position: refs/heads/master@{#419047} Commit : 0ad321336ed38d8a281d2da084013cf1e29b2ce0 Date : Fri Sep 16 00:16:38 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@419044 166507 1101.09 5 good chromium@419046 165996 1681.35 5 good chromium@419047 193704 868.742 5 bad <-- chromium@419048 193506 397.879 5 bad chromium@419052 192930 947.821 5 bad chromium@419059 193372 429.841 5 bad chromium@419073 193722 1286.52 5 bad chromium@419105 193874 693.601 5 bad Bisect job ran on: winx64_zen_perf_bisect Bug ID: 648644 Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --also-run-disabled-tests storage.indexeddb_endure Test Metric: vm_working_set_final_size_total/vm_working_set_final_size_total Relative Change: 16.44% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64_zen_perf_bisect/builds/487 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000984730034867264 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5779112289894400 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Tests>AutoBisect. Thank you!
,
Sep 20 2016
,
Sep 21 2016
For the duped issue 648641 this does seem likely to be caused by shader compiles. This test is a bit unrealistic, because it starts with a fresh profile and because of that the shader disk cache is empty. Maybe it would make sense to load another page first which could ensure the memory shader cache is full with a normal set of shaders.
,
Sep 21 2016
Ok, this makes sense - the page with the terrible (4000%) regression is the first one to run, so it needs to load 100% of its shaders and doesn't benefit from the memory or disk caches. +1 to loading another (unrelated) page first to give a more realistic "warm" cache.
,
Sep 21 2016
,
Sep 21 2016
Also interesting is overlay_background_color_css_transitions.html, which seems to be a large part of the regression from smoothness.tough_animation_cases https://chromeperf.appspot.com/report?sid=7c5e2e9e033465c97b46d13feda1454ac3a6c5cd49820f016f246d59f129642d&start_rev=416084&end_rev=420026
,
Sep 21 2016
,
Sep 28 2016
Everything except frame_times improved at https://chromium.googlesource.com/chromium/src/+log/6a3cc7f4a4b8d30e4f9b6f305a279fa3853b24b9%5E..2ab73add8ee95ef4385b91c8e5c982aa645a13a8?pretty=fuller ? I don't see any changes that should have made a difference.
,
Sep 28 2016
opened a bug crbug.com/651229 to run a bisect - hopefully this will change for us and we can decide if it's real/an error.
,
Sep 29 2016
Re #10 - Seems like fieldtrial configs were broken for a bit - this should be going back to our previous behavior today - see crbug.com/649363
,
Oct 1 2016
,
Oct 4 2016
I've been investigating the memory usage regression, and it seems like a large portion of the memory is used for the font texture atlas. Reducing its height from 2048 to 512 reduces GPU memory usage from around 59MB to 55MB (so maybe there are 2 copies)?
,
Oct 4 2016
There could be multiple atlas textures if we have a mix of mask types (LCD text, grayscale text, 32bit color emoji).
,
Oct 4 2016
Interesting - I wonder what the performance trade-offs are - it would be good to figure out how much of the atlas is used under typical circumstances. FWIW - on desktop we've been fairly OK with small/moderate memory increases, as long as there's a justification for them (Android is where we really haven't been wanting GPU raster memory increases to slip in). Of course, if we can reduce the size of the atlas without hurting performance, this seems like a win/win. In case you haven't seen it, memory-infra tracing might be useful in seeing what allocations (from what process) are using up GPU memory. (more info is here: https://chromium.googlesource.com/chromium/src/+/master/components/tracing/docs/memory_infra.md).
,
Oct 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7ac9b1b7052cc76fa7b3fef51d2dc447f55991d3 commit 7ac9b1b7052cc76fa7b3fef51d2dc447f55991d3 Author: jbauman <jbauman@chromium.org> Date: Fri Oct 07 16:51:08 2016 Add 1 second delay before gestures in smoothness.top_25_smooth With GPU rasterization there's a one-time startup cost of doing shader compiles for skia. The tests were starting their gestures almost immediately after load, so they were sometimes forced to wait for the shader compiles to happen before the first gesture. This test was intended to test scrolling smoothness, not time to first paint, so adding a delay makes them more consistent. In the real world these shaders are most likely cached on disk or in memory, so any load after the browser was running a while should be better. BUG= 648644 Review-Url: https://codereview.chromium.org/2354243004 Cr-Commit-Position: refs/heads/master@{#423886} [modify] https://crrev.com/7ac9b1b7052cc76fa7b3fef51d2dc447f55991d3/tools/perf/page_sets/top_25_smooth.py
,
Nov 23 2016
It looks like the original regression reverted, but there was a new regression that happened before your fix landed, so it's going to be difficult to prove the latest CL made any noticeable changes.
,
Nov 23 2016
,
Dec 6 2016
The majority of these issues have recovered. The only remaining issues which are a bit concerning are the "frame_times" measurements. I haven't been able to reproduce these results locally (frame_times generally improved for me). We should confirm whether the frame time regression is from one *really* slow frame at start, caused by shader compilation. If so, this can probably be safely ignored.
,
Mar 30 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983661746989281408
,
Mar 31 2017
=== BISECT JOB RESULTS === Bisect was unable to run to completion Error: INFRA_FAILURE The bisect was able to narrow the range, you can try running with: good_revision: fd3d9084805b6f598ee9cb9525de745b3209e5c0 bad_revision : 19c6a0755a478b6d759a98e1f12adfac8a6a6cfb If failures persist contact the team (see below) and report the error. Bisect Details Configuration: winx64_zen_perf_bisect Benchmark : smoothness.tough_animation_cases Metric : frame_times/frame_times Revision Result N chromium@419033 19.7123 +- 0.0439654 6 good chromium@419043 19.7077 +- 0.0660692 6 good chromium@419052 20.4892 +- 0.111116 6 bad chromium@419070 20.4635 +- 0.0828026 6 bad chromium@419106 20.4804 +- 0.0800047 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests smoothness.tough_animation_cases Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983661746989281408 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=4841229113622528 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Mar 31 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983570039369378304
,
Mar 31 2017
Took a detailed look - most of the aggregate frame_times regression here is from: smoothness.tough_animation_cases overlay_background_color_css_transitions.html See the discussion in bug 649184 - I don't think this is an issue. Other issues have recovered.
,
Apr 1 2017
=== BISECT JOB RESULTS === Bisect was unable to run to completion Error: INFRA_FAILURE The bisect was able to narrow the range, you can try running with: good_revision: fd3d9084805b6f598ee9cb9525de745b3209e5c0 bad_revision : 19c6a0755a478b6d759a98e1f12adfac8a6a6cfb If failures persist contact the team (see below) and report the error. Bisect Details Configuration: winx64_zen_perf_bisect Benchmark : smoothness.tough_animation_cases Metric : frame_times/frame_times Revision Result N chromium@419033 19.8616 +- 0.0764617 6 good chromium@419043 19.8816 +- 0.0653416 6 good chromium@419052 20.7531 +- 0.154879 6 bad chromium@419070 20.7478 +- 0.205568 6 bad chromium@419106 20.6721 +- 0.0716675 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests smoothness.tough_animation_cases Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983570039369378304 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=4841229113622528 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Apr 2 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983388779475082144
,
Apr 2 2017
=== Auto-CCing suspected CL author jbauman@chromium.org === Hi jbauman@chromium.org, the bisect results pointed to your CL, please take a look at the results. === BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : jbauman Commit : 0ad321336ed38d8a281d2da084013cf1e29b2ce0 Date : Fri Sep 16 00:16:38 2016 Subject: Enable GPU rasterization on Windows Intel Broadwell and later GPUs. Bisect Details Configuration: winx64_zen_perf_bisect Benchmark : smoothness.top_25_smooth Metric : mean_input_event_latency/http___games.yahoo.com Change : 100.83% | 11.5883333333 -> 23.2731666667 Revision Result N chromium@419044 11.5883 +- 0.402143 6 good chromium@419046 10.7732 +- 2.05159 6 good chromium@419047 24.6905 +- 10.3407 6 bad <-- chromium@419048 22.9967 +- 4.93446 6 bad chromium@419052 23.635 +- 5.41953 6 bad chromium@419059 27.4697 +- 10.3282 6 bad chromium@419073 24.2698 +- 5.82465 6 bad chromium@419105 23.2732 +- 4.68706 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...games.yahoo.com smoothness.top_25_smooth Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983388779475082144 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=4841229113622528 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jasontiller@chromium.org
, Sep 20 2016