Issue metadata
Sign in to add a comment
|
338.7%-409.4% improvement in blink_perf.canvas at 514655:514773 |
||||||||||||||||||||
Issue descriptionSuspiciously large improvement, what broke?
,
Nov 10 2017
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/10670256f80000
,
Nov 10 2017
📍 Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/10670256f80000
,
Nov 10 2017
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/14da8f5ef80000
,
Nov 10 2017
📍 Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/14da8f5ef80000
,
Nov 10 2017
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/14a390def80000
,
Nov 10 2017
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/177c286ef80000
,
Nov 10 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8963299236468406992
,
Nov 10 2017
📍 Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/177c286ef80000
,
Nov 10 2017
📍 Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/14a390def80000
,
Nov 10 2017
The bots aren't finding this :(
,
Nov 10 2017
=== Auto-CCing suspected CL author tguilbert@chromium.org === Hi tguilbert@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 : Thomas Guilbert Commit : d8540741f175eab5b502b5f3cf75ebefe837daab Date : Wed Nov 08 05:03:46 2017 Subject: Remove blocking call to VideoFrameCompositor Bisect Details Configuration: winx64nvidia_perf_bisect Benchmark : blink_perf.canvas Metric : upload-video-to-texture/upload-video-to-texture Change : 362.22% | 90646.7641402 -> 418991.313106 Revision Result N chromium@514600 90646.8 +- 19191.2 6 good chromium@514725 83749.9 +- 16107.3 6 good chromium@514757 79142.6 +- 14907.0 6 good chromium@514758 392385 +- 64602.7 6 bad <-- chromium@514759 372008 +- 31313.9 6 bad chromium@514761 366863 +- 98143.7 6 bad chromium@514765 384803 +- 49830.2 6 bad chromium@514773 399344 +- 49457.5 6 bad chromium@514788 368996 +- 87566.5 6 bad chromium@514850 418991 +- 94522.6 6 bad Please refer to the following doc on diagnosing blink_perf regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md 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 blink_perf.canvas More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8963299236468406992 For feedback, file a bug with component Speed>Bisection
,
Nov 13 2017
Some context: the large increase in performance is expected. Previously, we would block the render thread, wait for the compositor thread to update the current frame, and then retrieve the current, updated frame. The bug referenced in the associated CL happens when there is too much work being done on the compositor thread, and the hang detector kicks in while we are blocked, waiting on the VideoFrameCompositor to update the frame. The culprit CL makes it so that we no longer block on the VideoFrameCompositor update, but instead just fetch the current frame, and then asks the VideoFrameCompositor to update the frame. This means that the method is a lot faster, but it also means that we can get frames that are slightly out of date. Are there any perf tests that measure frame accuracy? The idea was that if there are no significant regression on frame accuracy, the perf improvements would justify being delayed by 1 frame.
,
Nov 21 2017
I don't think there is anything to fix here. Please re-open the bug if any adverse effects are found. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 10 2017