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

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


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

android-nexus6
android-nexus7v2
android-webview-nexus5X
android-webview-nexus6

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8974467559290371664

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8974467509589642512

=== BISECT JOB RESULTS ===
NO Perf regression found

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : speedometer
  Metric       : FlightJS-TodoMVC/FlightJS-TodoMVC

Revision             Result                  N
chromium@484852      1551.46 +- 118.822      21      good
chromium@484907      1572.68 +- 198.154      21      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests speedometer

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8974467559290371664


For feedback, file a bug with component Speed>Bisection

=== Auto-CCing suspected CL author delphick@chromium.org ===

Hi delphick@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 : Dan Elphick
  Commit : 67fac36a35318d03fe141887898821e42dfaecb4
  Date   : Fri Jul 07 08:57:32 2017
  Subject: Increase priority of compositor TQ in NONE Usecase

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : speedometer
  Metric       : React-TodoMVC/React-TodoMVC
  Change       : 3.64% | 6624.17 -> 6865.316

Revision             Result                  N
chromium@484852      6624.17 +- 187.202      6      good
chromium@484859      6640.3 +- 218.876       9      good
chromium@484861      6639.82 +- 228.812      6      good
chromium@484862      6639.8 +- 140.7         6      good
chromium@484863      6873.57 +- 148.914      6      bad       <--
chromium@484866      6887.93 +- 351.675      6      bad
chromium@484880      6884.27 +- 268.663      6      bad
chromium@484907      6865.32 +- 137.255      5      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests speedometer

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8974467509589642512


For feedback, file a bug with component Speed>Bisection

 Issue 740925  has been merged into this issue.

 Issue 740926  has been merged into this issue.

 Issue 740926  has been merged into this issue.

 Issue 741734  has been merged into this issue.

Issue 741743 has been merged into this issue.

 Issue 741716  has been merged into this issue.

 Issue 741716  has been merged into this issue.

delphick@, it looks like this is responsible for quite a few regressions, including a nontrivial (5%) regression in total CPU used by Chrome across a lot of pages. Are these regressions expected? Are you planning to revert this?

Some performance changes would be expected, although I would have expected at least some positive performance changes which aren't showing up here (possibly because they were minor and thus not bisected).

My one idea is that by prioritizing compositor work over default timers, we may increase frame rate causing a test to run for more frames before completing which could increase both the time to run and CPU usage (depending on how it's calculated). This is probably a good thing but needs some investigation.

I will revert and take a longer look.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4b9c6f94315e003ef4742c192e81252a823d7682

commit 4b9c6f94315e003ef4742c192e81252a823d7682
Author: Dan Elphick <delphick@chromium.org>
Date: Mon Jul 17 12:27:56 2017

Revert "Increase priority of compositor TQ in NONE Usecase"

This reverts commit 67fac36a35318d03fe141887898821e42dfaecb4.

Reason for revert: Causes several CPU load, time and memory regressions. Fixes crbug/740469

Original change's description:
> Increase priority of compositor TQ in NONE Usecase
> 
> This allows animated GIFs to keep updating even in the presence of timer
> storms.
> 
> Reland change partially reverted in
> WebRtc and CrSettings tests have been landed.
> 
> https: //chromium-review.googlesource.com/c/508792/ now that fixes to
> Bug: 703608
> Change-Id: Id014fda26b7168658c679a7bf74359485c5262e5
> Reviewed-on: https://chromium-review.googlesource.com/559345
> Reviewed-by: Sami Kyöstilä <skyostil@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#484863}

TBR=skyostil@chromium.org,delphick@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 703608,  740469 
Change-Id: I172f61626446462bb5582c942ae58d09a13dad71
Reviewed-on: https://chromium-review.googlesource.com/573902
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Alex Clarke <alexclarke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487051}
[modify] https://crrev.com/4b9c6f94315e003ef4742c192e81252a823d7682/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl.cc
[modify] https://crrev.com/4b9c6f94315e003ef4742c192e81252a823d7682/third_party/WebKit/Source/platform/scheduler/renderer/renderer_scheduler_impl_unittest.cc