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

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


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

android-nexus5

cc test owners.

The first bisect failed with "Failed steps failed gathering reference values.performance test 1 of 5 failed gathering reference values.reading chartjson results"

https://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/3616

I kicked another bisect with another test in the grouped tests.

Another run results in the same error.

kicked another bisect because the blocking issue was fixed

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

Hi wychen@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


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


===== SUSPECTED CL(s) =====
Subject : Add ReaderModeUI to the fieldtrial for Clank
Author  : wychen
Commit description:
  
BUG=

Review URL: https://codereview.chromium.org/1910183003

Cr-Commit-Position: refs/heads/master@{#389168}
Commit  : 195357ccde3698de752115be6df0a6cb3abcc5be
Date    : Fri Apr 22 18:25:28 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@389154         38.790253   0.234638    5           good
chromium@389167         39.124129   0.5904      8           good
chromium@389168         40.341908   0.295258    5           bad         <-
chromium@389169         40.424229   0.269018    8           bad
chromium@389170         40.42938    0.294226    8           bad
chromium@389173         40.490605   0.240965    8           bad
chromium@389179         40.719011   0.423059    8           bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 606258

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.tough_scrolling_cases
Test Metric: thread_total_all_cpu_time_per_frame/thread_total_all_cpu_time_per_frame
Relative Change: 5.42%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/3622
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014341555872466112


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

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

There's also a 2KB increase in vm_private_dirty_final_browser.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re #7: It's 2MB, not 2KB.

Perf sheriff ping

wychen@: do you think this was a real regression caused by r389168? If was, was it a trade-off? Is there anything that can be done to fix the regression?

Hey Ted, can we get some cycles from your team to investigate?

The only thing the listed change does is enable reader mode for testing on the bots. Since the change encompasses the entire feature, I'm not sure it's going to be possible to isolate the single cause of this particular regression.

Assigning to wychen@ to investigate more.  As mdjones@ points out, this would be hard to isolate to a particular issue, but I'm curious what this perf test is looking at.  

""Measure timeline metrics while performing smoothness action on tough scrolling cases.""

Is it loading a page and immediately trying to scroll?  Reader mode does do some calculation early-ish on load to determine if the page is distillable.  I don't know if we have metrics about how long that takes, but that should give us some insight into what is going on here.

Maybe we could track whether a user gesture is currently happening on the page before we kick off the calculation as the UI is going to not be shown on scroll (so I don't think that is specifically gaming the perf metric either).

wychen@ is OOO for a while, and he is the best person to investigate this more so I'm going to assign to him and see if we can think more about how to alleviate any perf impact this had.

It looks like the window to fix this has passed.