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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwsT_sgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwtfgqAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwsLxvgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgosCNtAkM


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

android-nexus5

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

Hi lethalantidote@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 : Refactor to make BlimpLocationProvider accessible to content layer.
Author  : lethalantidote
Commit description:
  
This change adds to ContentBrowserClient the ability to indicate whether one should use NetworkLocationProvider objects when accessing location data. The LocationArbitratorImpl now checks this boolean to determine what LocationProviders to create and register, allowing for system/override location providers to be used without the network location providers.

BlimpContentBrowserClient is updated to use these changes to indicate that NetworkLocationProvider objects should not be used. It also provides a BlimpLocationProvider through OverrideSystemLocationProvider. Since UseNetworkLocationProviders returns false, and we supply the override, Blimp will only use the BlimpLocationProvider for querying location.

Other additions:
* Moved non-NetworkLocationProvider creation out into a separate function to allow for optional instantiation of NetworkLocationProvider objects.
* Moved call to UseNetworkLocationProviders() so that its result is now passed to LocaitonArbitratorImpl through to GeolocationProviderImpl. This was done to give a better way to test the codepath for the case that UseNetworkLocationProviders returns false.

BUG=614486

Review-Url: https://codereview.chromium.org/2028823002
Cr-Commit-Position: refs/heads/master@{#401453}
Commit  : 564907f6ecd1040e0074aeeadf7da5e2ec7fdde6
Date    : Wed Jun 22 23:21:12 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@401408  2.82134  0.0177579  5   good
chromium@401432  2.83528  0.0153589  5   good
chromium@401444  2.82961  0.0273034  5   good
chromium@401450  3.22273  0.131159   12  good
chromium@401452  3.25242  0.0315484  12  good
chromium@401453  3.41421  0.255191   12  bad    <--
chromium@401455  3.31892  0.0286052  5   bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 623059

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.simple_mobile_sites
Test Metric: thread_renderer_compositor_cpu_time_per_frame/thread_renderer_compositor_cpu_time_per_frame
Relative Change: 17.64%
Score: 95.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/3763
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9008965489795582704


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5810200490016768

| 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!

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

lethalantidote: Ping!

I am not sure at this point how my CL could be causing the regression, since it is an addition of a virtual method that is only called when using geolocation. Looking at the bisect, 401450 seems likely where the regression has occurred, which seems right since it is a compositor change. 

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

Perf sheriff ping.

Note, this bug is only associated with alerts from one platform, and it hasn't been conclusively confirmed yet.

All graphs has returned to pre-regression levels.

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@401408  2.80521  0.0687054  12  good
chromium@401432  2.80797  0.0786141  18  good
chromium@401444  2.79655  0.0676684  12  good
chromium@401450  2.86563  0.261485   8   good
chromium@401453  2.7429   0.0197001  5   good
chromium@401455  3.17002  0.307006   18  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 623059

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.simple_mobile_sites
Test Metric: thread_renderer_compositor_cpu_time_per_frame/thread_renderer_compositor_cpu_time_per_frame
Relative Change: 11.33%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4004
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004058474944888064


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5875694203043840

| 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!

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

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@401408  2.80521  0.0687054  12  good
chromium@401432  2.80797  0.0786141  18  good
chromium@401444  2.79655  0.0676684  12  good
chromium@401450  2.86563  0.261485   8   good
chromium@401453  2.7429   0.0197001  5   good
chromium@401455  3.17002  0.307006   18  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 623059

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.simple_mobile_sites
Test Metric: thread_renderer_compositor_cpu_time_per_frame/thread_renderer_compositor_cpu_time_per_frame
Relative Change: 11.33%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4004
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004058474944888064


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5875694203043840

| 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!

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

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

Hi vmpstr@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 : cc: Remove fixed raster scale, stop rasterizing with will-change.
Author  : vmpstr
Commit description:
  
This patch replaces the current behavior of blocking all new scales
once the ideal scale changes once. The new behavior looks at a
will-change transform property:

- If will-change is present, we don't reraster or choose a new scale.
- If will-change is absent, we keep rerastering at a new scale.

R=danakj@chromium.org, chrishtr@chromium.org
BUG= 600867 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2068413002
Cr-Commit-Position: refs/heads/master@{#401450}
Commit  : edd476edadbe9b9316f3527b0692836ced4230ce
Date    : Wed Jun 22 23:16:34 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N   Good?
chromium@401408  18.9775  0.275863  18  good
chromium@401432  19.0215  0.237514  18  good
chromium@401444  19.0689  0.301721  12  good
chromium@401447  18.9224  0.113089  8   good
chromium@401449  18.9669  0.25771   8   good
chromium@401450  20.0455  0.709207  8   bad    <--
chromium@401455  20.0531  0.932935  12  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 623059

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.simple_mobile_sites
Test Metric: thread_total_all_cpu_time_per_frame/thread_total_all_cpu_time_per_frame
Relative Change: 6.54%
Score: 99.5

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4015
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004058474944888064


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5875694203043840

| 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!