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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=a560498902efb1d1687316122cc182ed33fcd3ede058f1b6a026c7539ebc0393


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

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16c8a064640000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/16c8a064640000

Remove lifecycle updates for preferred content size changes by pdr@chromium.org
https://chromium.googlesource.com/chromium/src/+/601fd07dc26269d097d6ef6bd90f1203d361a72c
49.67 → 71.01 (+21.34)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15fb4bc8640000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/15fb4bc8640000

Buildbucket says the build completed successfully, but Pinpoint can't find the isolate hash.

These perf results are not obvious. I think I understand the rendering.desktop results, and I think they have improved.

On a very high end machine (my laptop), the test balls_css_transition_all_properties is clearly improved. More begin frames occur with the patch which explains how tasks per frame is rising.

On a not-as-high-end machine like mac-10_12_laptop_low_end-perf, the results are harder to interpret. The begin frame count actually drops with the patch which seems bad. This test moves balls in a setTimeout and what's happening is that fewer balls are being moved per frame without the patch. This can be seen in the PaintController::commitNewDisplayItems trace events:
before patch:
  current_display_list_size 2501
  num_non_cached_new_items 845
after patch:
  current_display_list_size 2501
  num_non_cached_new_items 2215
Before the patch, fewer balls are moving per frame which is why there are more begin main frames before the patch, and why each begin main frame is cheaper before the patch.


I still need to look into the layout perf differences and the android-specific perf differences.

Due to the analysis in comment #6. We have a separate layout regression that is real and is tracked in  https://crbug.com/872599 .

 Issue 872678  has been merged into this issue.

 Issue 874873  has been merged into this issue.