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

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


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

chromium-rel-mac11

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

Hi dglazkov@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 : TextIteratorAlgorithm should not force layout update in constructor.
Author  : dglazkov
Commit description:
  
This is a third attempt at landing this (which time is the charm? I forget). Yay!

Asking to update layout should not be done at this level -- updating layout is part of the document/view lifecycle and should be coordinated at a higher level than an iterator constructor.

Thus, move calling Document::updateLayoutIgnorePendingStylesheets up to the callsites of the TextIterator constructor. These callsites should be audited and moved up even farther up the call stack.

BUG= 590295 
R=esprehn,yosin

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

Cr-Commit-Position: refs/heads/master@{#389355}
Commit  : a3eecad9b893616b8666e11da69d6ea28c85b6bf
Date    : Sat Apr 23 03:37:24 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@389337         199.56287   1.271974    5           good
chromium@389350         201.815883  3.569511    5           good
chromium@389354         203.068987  2.912402    5           good
chromium@389355         179.261106  0.863277    5           bad         <-
chromium@389356         180.176181  0.716667    5           bad
chromium@389357         180.417071  0.932615    5           bad
chromium@389363         179.674864  0.795002    5           bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 606245

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.bindings
Test Metric: id-setter/id-setter
Relative Change: 9.97%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/600
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9014431011573224688


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

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

id-setter: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/PerformanceTests/Bindings/id-setter.html&q=id-setter.html&sq=package:chromium&l=1

Looks like it's just setting id in a tight loop. If my change regressed it, we've got much bigger problems. Let me try to investigate...

dglazkov@ : Could you please take a look into this and update further seems like the alerts are not recovered.
https://chromeperf.appspot.com/group_report?bug_id=606245

Are we looking at a different bug? It looks like it did recover?

Deleted: Screenshot 2016-05-06 at 8.34.38 AM.png 20.1 KB

	Screenshot 2016-05-06 at 8.34.38 AM.png 20.1 KB View Download

Looks recovered to me, too, but need to stretch out the bottom graph to see the full picture.