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

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


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

android-nexus5X

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

This may be invalid - the ref is changing but not by as much.

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

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : blink_perf.css
  Metric       : SelectorCountScaling/SelectorCountScaling

Revision             Result                  N
chromium@451825      18.0186 +- 23.955       21      good
chromium@452845      19.1168 +- 31.2795      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 blink_perf.css

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

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


| 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 Speed>Bisection.  Thank you!

Not sure how much more time we need to spend on this. We found a big regression, but bisection didn't work well.

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

The regression looks more stable on linux-release:

https://chromeperf.appspot.com/report?sid=a8b998b0ef1d72851c1e98cb621fee3757eb7806322a01bb17cc39cdbc225142&start_rev=431794&end_rev=456905

I've triggered a bisect job for that platform.

=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Michael Hablich
  Commit : 7c3936c67a6361371d9a00d83e2c03ecc603ce76
  Date   : Thu Mar 09 08:05:42 2017
  Subject: Version 5.9.34.1 (Turn on I+TF)

Bisect Details
  Configuration: linux_perf_bisect
  Benchmark    : blink_perf.css
  Metric       : SelectorCountScaling/SelectorCountScaling
  Change       : 21.02% | 206.998138543 -> 163.480599665

Revision                           Result                   N
chromium@455679                    206.998 +- 1.37821       6      good
chromium@455702                    207.02 +- 2.01548        6      good
chromium@455713                    205.564 +- 0.729201      6      good
chromium@455719                    208.501 +- 1.65548       6      good
chromium@455719,v8@7c3936c67a      162.663 +- 1.95503       6      bad       <--
chromium@455719,v8@fbffc377e3      163.177 +- 2.0126        6      bad
chromium@455720                    162.224 +- 1.03148       6      bad
chromium@455721                    164.669 +- 1.83909       6      bad
chromium@455722                    163.442 +- 2.07215       6      bad
chromium@455724                    164.127 +- 1.6696        6      bad
chromium@455768                    163.481 +- 0.614352      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.css

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

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


| 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 Speed>Bisection.  Thank you!

rune@ you merged this into the memory regression bug, are you sure that's right? This seems like the I+TF enable caused a huge regression in this benchmark.

Should this have been tracked by  issue 698746  instead of duped?

Re #9 merging happens automatically. There is no way to prevent that.

Re #10 please block the mentioned bug like it is now.

mvstanton@, any update on this?

The ref build also regressed and got more flaky at the same time. Recheck if this is not simply a bot problem

It looks like SelectorCountScaling has recovered completely.