New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 783692 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

338.7%-409.4% improvement in blink_perf.canvas at 514655:514773

Project Member Reported by alexclarke@chromium.org, Nov 10 2017

Issue description

Suspiciously large improvement, what broke?
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=783692

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=a3d3899151a2c1ae116bc68f10c54c73e037cf3ff1bec423c31fb28bda9eb413


Bot(s) for this bug's original alert(s):

chromium-rel-mac11
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-win7-gpu-nvidia
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/10670256f80000
Project Member

Comment 5 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14da8f5ef80000
Project Member

Comment 9 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/177c286ef80000
Project Member

Comment 10 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14a390def80000
Status: WontFix (was: Untriaged)
The bots aren't finding this :(
Project Member

Comment 12 by 42576172...@developer.gserviceaccount.com, Nov 10 2017

Cc: tguilbert@chromium.org
Owner: tguilbert@chromium.org
Status: Assigned (was: WontFix)

=== 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
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.
Status: WontFix (was: Assigned)
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