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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgibng7gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgibng7gsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyenDrAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyYukoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyd64rAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgic-LtwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgybfgugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgic-frgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyYTxqAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgycasowoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgydCdugsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyfzBpAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyfnWrwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyZ3osAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyY34_AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgyeavqgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgydmEvwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqdD9qAoM


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

chromium-rel-win10
chromium-rel-win8-dual

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

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

Hi hiroshige@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 : [WeakMemoryCache] Make references from MemoryCache to Resource Weak
Author  : hiroshige
Commit description:
  
Design doc (Step 1):
https://docs.google.com/document/d/1Pj4vzxzCKC_11SugdJ_x7wq7ErE-pHtf4w4FLKdcF7g/edit?usp=sharing

This cl relands
- https://codereview.chromium.org/1915113005
- https://codereview.chromium.org/2066763002
except for code related to Field-Trial or SharedBuffer::unlock().

BUG=603462

Review-Url: https://codereview.chromium.org/2296913003
Cr-Commit-Position: refs/heads/master@{#417245}
Commit  : 581fd42e219de5510f0fd7729e7b00a411ff68a8
Date    : Thu Sep 08 10:59:20 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@417242  21.1754  0.794879  5  good
chromium@417244  21.79    1.74011   5  good
chromium@417245  35.4218  2.88939   5  bad    <--
chromium@417248  34.515   1.70433   5  bad
chromium@417253  34.7926  1.82899   5  bad

Bisect job ran on: winx64_10_perf_bisect
Bug ID: 645363

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: CrawFishGanson/CrawFishGanson
Relative Change: 64.31%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64_10_perf_bisect/builds/714
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9002018441496548240


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

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

Hmm. Reproduced locally on Linux.

This regression is because XHR in PerfTestRunner.loadFile() in third_party/WebKit/PerformanceTests/resources/runner.js.

The performance test loads an SVG 5 times.
Previously, the XHR hits MemoryCache in each iteration.
After my CL, the XHR doesn't hit MemoryCache and initiate a new loading.
This is because GC is executed (in scheduleNextRun()?) between iterations which destructs the RawResource for XHR.

Disabling cache for the XHR (by adding '?' + Math.random()) results in the comparable performance before and after my CL.

Therefore, I think this regression is not related to SVG and is safe to ignore in the context of SVG.

And because loadFile() is only called from measurePageLoadTime() that is only called from blink_perf.svg tests, this only regressed blink_perf.svg.

Draft CL: https://codereview.chromium.org/2323313002/

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

commit f553491c9104f998b48f50c66da1b14473af053d
Author: hiroshige <hiroshige@chromium.org>
Date: Wed Sep 14 07:59:53 2016

Load the test page before measurement in PerfTestRunner.measurePageLoadTime()

Previously, loadFile() is called to load the test page during performance
measurement in PerfTestRunner.measurePageLoadTime(), and thus the results of
blink_perf.svg tests were affected by the performance of loadFile() (that is not
related to SVG).
This CL makes the loadFile() to be executed before measurement and thus avoids
blink_perf.svg regressions caused by loadFile() performance regression.

The loadFile() performance regression is caused by [1] because, after [1],
synchronous XHRs are evicted from MemoryCache when Oilpan GC is executed.
[1] https://codereview.chromium.org/2296913003
This is expected and we can ignore the regression unless it causes regressions
in real use cases.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
BUG= 645363 

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

[modify] https://crrev.com/f553491c9104f998b48f50c66da1b14473af053d/third_party/WebKit/PerformanceTests/resources/runner.js

The graph recovered by the fix (Comment #7). Closing.