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

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


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

chromium-rel-mac11-pro

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

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

Hi pfeldman@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 : pfeldman
  Commit : e92e6c7d3830bf4d01d364d30b77ab1bb168bc21
  Date   : Sat Mar 11 17:55:22 2017
  Subject: DevTools: resurrect flow events rendering on the flame chart.

Bisect Details
  Configuration: mac_pro_perf_bisect
  Benchmark    : blink_perf.dom
  Metric       : div-editable/div-editable
  Change       : 0.86% | 1.15408255165 -> 1.14419266446

Revision             Result                     N
chromium@456279      1.15408 +- 0.0363311       21      good
chromium@456283      1.15814 +- 0.0261764       14      good
chromium@456285      1.15779 +- 0.00957166      6       good
chromium@456286      1.14366 +- 0.0398904       14      bad       <--
chromium@456288      1.14419 +- 0.0337558       14      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.dom

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

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


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

@sullivan: something is fishy here. Title is saying 14.3%, bisect is saying 0.86%, so we missed most of the attribution for the regression.

As for the 0.86% itself, I added a couple of trace events in a new category that are not disabled by default. That's zero overhead. Could it be that you are enabling categories not disabled by default while measuring blink.perf?

Sorry about this! It looks like:

* It only happened on one bot
* The ref build dips at the same time, so likely due to a bot change.