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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglo-y4gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1orVtQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1qyFswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1vrr5QkM


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

android-webview-nexus6

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

=== Auto-CCing suspected CL author mstensho@opera.com ===

Hi mstensho@opera.com, 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 : Morten Stenshorne
  Commit : 4aad5b967dc3c9405565f8a7274d2ff9c37e6405
  Date   : Mon Jun 12 14:42:54 2017
  Subject: Better handling of min/max widths that depend on the containing block.

Bisect Details
  Configuration: android_webview_nexus6_aosp_perf_bisect
  Benchmark    : blink_perf.layout
  Metric       : nested-percent-height-tables/nested-percent-height-tables
  Change       : 12.92% | 131.467252464 -> 114.482438532

Revision             Result                   N
chromium@478612      131.467 +- 1.23931       9      good
chromium@478614      130.004 +- 2.05677       6      good
chromium@478615      133.383 +- 3.09305       6      good
chromium@478616      115.137 +- 2.4647        6      bad       <--
chromium@478619      115.323 +- 1.37671       6      bad
chromium@478625      114.463 +- 3.02324       6      bad
chromium@478637      114.482 +- 0.678985      5      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.layout

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

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


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

While it isn't unreasonable to suspect this CL for such a performance regression, I can't reproduce it locally.

I did five runs with the CL and five with the CL reverted (numbers are average runs per second):

ToT: 3929 3941 3941 3925 3906
Suspected CL reverted: 3938 3922 3923 3980 3973

So, if we assume that there's absolutely no noise in the data here (which there is, of course), I can measure a slowdown of 0.5%, which just seems like a reasonable price to pay for better layout in percent height situations.

But I ran this on a Linux workstation, not on an Android device. I'll take a closer look at my changes and see if I can come up with a speculative fix or something.

FWIW most of the regressions were detected on webview (32 bit), and one on a tablet. So there might be something specific to those environments?

Speculative fix landed here: https://chromium-review.googlesource.com/c/538658/

But the bot was asleep and didn't comment here.

Any chance that you can see if the performance problem is gone?

 Issue 734577  has been merged into this issue.

Fixed in the range http://test-results.appspot.com/revision_range?start=480769&end=480776 - the speculative fix is within range.