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

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


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

android-nexus6

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

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Support early associated interface binding on ChannelMojo
Author  : rockot
Commit description:
  
Changes the associated bindings implementation for ChannelMojo
such that remote interfaces can be acquired immediately upon
ChannelMojo construction rather than having to wait for connection
on the IO thread.

Simplifies the Channel bootstrapping process, removing a round-trip
Init message (and in fact the entire IPC::mojom::Boostrap interface)
since there's no need to actually exchange associated interface handles
over the pipe. Instead both sides can assume the other will use a fixed,
reserved endpoint ID for their IPC::mojom::Channel interface.

This also removes the restriction that associated interfaces must be
added to a Channel after Init. Instead the same constraints apply as
with AddFilter: an associated interface, like a filter, may be added
at any time as long as either Init hasn't been called OR the remote
process hasn't been launched.

The result of this CL is that any place it's safe to AddFilter,
it's also safe to AddAssociatedInterface; and any place it's safe to
Send, it's also safe to GetRemoteAssociatedInterface and begin using
any such remote interface immediately.

Remote interface requests as well as all messages to remote interfaces
retain FIFO with respect to any Send calls on the same thread. Local
interface request dispatch as well as all messages on locally bound
associated interfaces retain FIFO with respect to any OnMessageReceived
calls on the same thread.

BUG=612500, 619202 

Committed: https://crrev.com/e1037f997da9e1d44ca3b09d4ff32f0465673091
Committed: https://crrev.com/508da24622f957a01b076ccd058bfdccc79068a4
Review-Url: https://codereview.chromium.org/2163633003
Cr-Original-Original-Commit-Position: refs/heads/master@{#406720}
Cr-Original-Commit-Position: refs/heads/master@{#407050}
Cr-Commit-Position: refs/heads/master@{#407264}
Commit  : 0e4de5f9a519c6cd206448a10eccc7a535e3db64
Date    : Fri Jul 22 21:20:12 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@407217  2092.72  1.60328  5  good
chromium@407244  2094.12  4.32739  5  good
chromium@407258  2092.29  3.49924  5  good
chromium@407262  2093.47  2.83043  5  good
chromium@407263  2090.34  2.12912  5  good
chromium@407264  2213.63  2.75384  5  bad    <--
chromium@407265  2212.55  3.08939  5  bad
chromium@407271  2214.99  4.27243  5  bad
chromium@407324  2214.75  4.18954  5  bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 631424

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.key_idle_power_cases
Test Metric: tasks_per_second_total_all/request-animation-frame.html
Relative Change: 5.83%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2344
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9006079884244153584


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

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