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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyY34_AoM


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

chromium-rel-win7-gpu-nvidia

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

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

Hi harkness@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 : Full hookup of BudgetManager interfaces to BudgetDatabase.
Author  : harkness
Commit description:
  
This includes changing the GetBudgetDetails on BudgetDatabase to use the mojo
types and plumbing the result through the BudgetManager. It pulls out all of
the old implementation in BudetManager that used the prefs to store data
(although cleanup of that isn't quite complete). It also replaces the old
GetBudget/StoreBudget calls in the push messaging system with the new Consume
call.

Tests were added in BudgetManager for the new reserve functionality, and any
tests of GetBudget that were still applicable were moved from BudgetManager
to BudgetDatabase.

BUG= 617971 

Review-Url: https://codereview.chromium.org/2281673002
Cr-Commit-Position: refs/heads/master@{#417236}
Commit  : 6f6b4143aa82b7876a8a0678e2cabb7074031ee5
Date    : Thu Sep 08 09:20:38 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N   Good?
chromium@417215  132.994  3.65059  93  good
chromium@417229  133.766  4.04562  93  good
chromium@417233  131.188  3.30971  27  good
chromium@417235  131.37   3.38021  18  good
chromium@417236  134.931  3.39051  93  bad    <--
chromium@417242  135.648  4.32991  93  bad

Bisect job ran on: winx64nvidia_perf_bisect
Bug ID: 645365

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.svg
Test Metric: Bamboo/Bamboo
Relative Change: 5.98%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64nvidia_perf_bisect/builds/1862
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9002018237232109632


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

| 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/8999178480817625424

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

Hi tzik@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 : Use per-frame task runner in XHR
Author  : tzik
Commit description:
  
The XHR spec describes progress events on XHR are queued on the networking
task source, where Networking task runner is the corresponding task runner.
https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send

BUG=624696

Review-Url: https://codereview.chromium.org/2269513002
Cr-Commit-Position: refs/heads/master@{#417230}
Commit  : f884e370f225e3cb7cde91f08dcc369952c7b863
Date    : Thu Sep 08 09:13:52 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N    Good?
chromium@417215  131.997  3.18688  12   good
chromium@417229  134.393  3.4104   140  good
chromium@417230  136.556  4.02834  41   bad    <--
chromium@417231  135.472  3.83182  140  bad
chromium@417233  135.114  3.16405  140  bad
chromium@417236  135.388  3.45768  41   bad
chromium@417242  135.633  2.38159  27   bad

Bisect job ran on: winx64nvidia_perf_bisect
Bug ID: 645365

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.svg
Test Metric: Bamboo/Bamboo
Relative Change: 4.80%
Score: 98.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64nvidia_perf_bisect/builds/1903
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8999178480817625424


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

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

I think it's not mine, but I'm OK to speculatively revert the CL.
Let's see the graph after the revert.

I actually suspect that the problem CL has already been reverted, because if you look at the graphs, they got significantly worse, then got better again. However, I wasn't able by inspection of the nearby CLs to determine what might have caused the degredation/improvement.

I re-ran the bisect yesterday accidentally. I was surprised that it came up with a different CL than previously. 

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

commit 9262bc8c2325f8bc299935df41d53e1725a91f07
Author: tzik <tzik@chromium.org>
Date: Thu Oct 13 08:50:48 2016

Revert of Use per-frame task runner in XHR (patchset #5 id:80001 of https://codereview.chromium.org/2269513002/ )

Reason for revert:
Speculative revert for  http://crbug.com/645365 . Will reland once it turns out being not the case.

Original issue's description:
> Use per-frame task runner in XHR
>
> The XHR spec describes progress events on XHR are queued on the networking
> task source, where Networking task runner is the corresponding task runner.
> https://xhr.spec.whatwg.org/#dom-xmlhttprequest-send
>
> BUG=624696
>
> Committed: https://crrev.com/f884e370f225e3cb7cde91f08dcc369952c7b863
> Cr-Commit-Position: refs/heads/master@{#417230}

TBR=haraken@chromium.org,skyostil@chromium.org,alexclarke@chromium.org,dcheng@chromium.org,yhirano@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=624696,  645365 

Review-Url: https://codereview.chromium.org/2407233002
Cr-Commit-Position: refs/heads/master@{#424985}

[modify] https://crrev.com/9262bc8c2325f8bc299935df41d53e1725a91f07/third_party/WebKit/Source/core/xmlhttprequest/XMLHttpRequestProgressEventThrottle.cpp

There was an improvement of this regression prior to the CL that landed in comment #8. However, the CL in comment #8 seems to have made the metric a bit less noisy. Closing this as fixed.