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

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


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

Android Nexus5X WebView Perf
Android Nexus6 WebView Perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

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

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

Roll AFDO from 73.0.3671.0_rc-r1 to 73.0.3672.0_rc-r1 by chromium-autoroll@skia-public.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/2c7da71a5d429c476dbe4351fa3b8fdec82ecefa
frame_times: 66.07 → 74.96 (+8.893)

Assigning to sheriff gbiv@chromium.org because "Roll AFDO from 73.0.3671.0_rc-r1 to 73.0.3672.0_rc-r1" is a roll.

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Thanks!

Looks like this was won back by the profile roll in r624467.

Looking back, there appears to be occasional AFDO-induced spikes (initially in a good direction!) for avg_surface_fps starting at r619337. The other charts either have fewer or less-substantial jumps, so I'd imagine that there's one cause for this.

Since this appears to be a loss of performance granted solely by a previous AFDO roll (rather than an outright regression in general), I don't have plans to try and force us back to a previous, unregressed profile before the branch.

 Issue 923440  has been merged into this issue.