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

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


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

android-nexus7v2

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

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

Hi thakis@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 : thakis
  Commit : f823f843f06636feb082521d76c282a16fe2d577
  Date   : Sat Jun 10 17:33:46 2017
  Subject: android: switch from gcc to clang.

Bisect Details
  Configuration: android_nexus7_perf_bisect
  Benchmark    : dromaeo.domcoremodify
  Metric       : dom/dom
  Change       : 8.86% | 42.758153429 -> 38.9687628795

Revision             Result                   N
chromium@478516      42.7582 +- 0.484516      6      good
chromium@478517      39.6545 +- 1.0456        6      bad       <--
chromium@478518      39.459 +- 0.97642        6      bad
chromium@478519      38.6848 +- 0.416046      6      bad
chromium@478521      38.9688 +- 0.844023      6      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 dromaeo.domcoremodify

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

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


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

 Issue 732288  has been merged into this issue.

 Issue 732290  has been merged into this issue.

Issue 732281 has been merged into this issue.

Dupes (in order):
10.1%-43.6% regression in blink_perf.css at 478516:478519
5.2%-5.3% regression in system_health.common_mobile at 478517:478517
1.3%-1.5% regression in system_health.memory_mobile at 1497151598:1497161932

(note that the change has in general been hugely positive, https://chromeperf.appspot.com/group_report?rev=478517 -- I still want to look at the (few) regressions that were included too)

 Issue 732988  has been merged into this issue.

12.7% regression in media.android.tough_video_cases at 478517:478521	

 Issue 732708  has been merged into this issue.

 Issue 732707  has been merged into this issue.

 Issue 734138  has been merged into this issue.

13% regression in blink_perf.layout at 478515:478516	
3.9% regression in thread_times.simple_mobile_sites at 478517:478517
13% regression in blink_perf.dom at 478517:478517

 Issue 734138  has been merged into this issue.

Explictly assigning. A CL you landed tripped one of the speed metrics we measure in the lab. If this is the first time this has happened to one of your CLs, or if it's been a while, please read: https://chromium.googlesource.com/chromium/src/+/master/docs/speed/addressing_performance_regressions.md

We're looking for one of the following:
1. Justification via explanation
2. Plan to revert or fix
3. Angry rage throwing of equipment at my head

Just be aware that I'm trained in trumpet playing and First Aid and am not afraid to use it.

Note: This was a bulk edit message and not very personal.

See comment 7. I do want to look at this, but this is the consequence of a change that overall was _hugely_ perf-positive.

 Issue 732291  has been merged into this issue.

11.6% regression in blink_perf.parser at 478516:478516	

This is on the perf sheriff list of bugs to ping: should we remove the Performance-Sheriff label since this appears to be tracked as part of a longer term effort on clang (and not a normal perf sheriff bug where we just decide whether to revert the offending CL)?

Yeah, all the dupes on this bug will be fixed when we reland the switch.

(Usual caveat: atm the perf waterfall doesn't measure what we ship on Windows, so the numbers here are not 100% right. After the switch, the perf waterfall will finally measure what we ship again though.)