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

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


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

android-nexus5
android-nexus6

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

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

Hi hiroshige@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 : hiroshige
  Commit : 0712ce38d1a05590e731d07f9aad4b46870f53ae
  Date   : Thu Jan 19 23:23:09 2017
  Subject: Call checkCompleted() synchronously in HTMLStyleElement::dispatchPendingEvent()

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : memory.top_10_mobile_stress
  Metric       : memory:chrome:all_processes:reported_by_chrome:cc:effective_size_avg/foreground/https_www_google_co_uk_hl_en_q_science
  Change       : 38.99% | 53477232.0 -> 74328602.6667

Revision             Result                    N
chromium@444875      53477232 +- 0.0           6      good
chromium@444883      53477232 +- 0.0           6      good
chromium@444885      53477232 +- 0.0           6      good
chromium@444886      74825225 +- 17094735      6      bad       <--
chromium@444887      69309996 +- 13695808      6      bad
chromium@444890      71156933 +- 5162851       6      bad
chromium@444905      70854547 +- 18115594      6      bad
chromium@444934      74328603 +- 8344369       6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

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 --story-filter=https.www.google.co.uk.hl.en.q.science memory.top_10_mobile_stress

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8989590729449052016

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6389390550499328


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

r430572 and r444886 affect the performance metrics in 
 https_www_google_co_uk_hl_en_q_science in memory.top_10_mobile_stress differently.

The graphs of this issue (cc:effective_size_avg on nexus5 and nexus6):
  improved by r430572 and regressed by r444886.
The graphs of  Issue 663823 :
  regressed by r430572 and improved/fixed by r444886.

The CLs affect timing around document load events and they not affect memory directly, I suspect the timing change only affects the timing when the memory consumption is measured and/or to which component the memory consumption is associated.

Can we close as WontFix?
+perezju@ as the test owner. WDYT?

Having a quick look over the graphs I would be inclined to say it's fine to WontFix.

Ben, could you just double check what in effect metrics returned to their baseline in both of those issues, and that they don't affect in strange ways numbers reported for system health (e.g. if any of those CLs is near a branch point).