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

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


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

Android Nexus5 Perf

blink_perf.image_decoder - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13de99b3640000

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

Roll AFDO from 70.0.3537.0_rc-r1 to 70.0.3538.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/050362316e5334755eceb55657233ef139255b34
1.314e+04 → 1.325e+04 (+118.2)

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

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

Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

Appears that this recovered and is stable as of a later roll: r588305

This is only the second obvious blip in the last ~month caused by AFDO, so I don't think there's much to do here WRT stabilization

For context, AFDO profiles are generated by sampling Chrome's execution and feeding that back into the compiler, so the compiler can better optimize Chrome. This process is inherently noisy, so we'll sometimes see benchmarks that are highly sensitive to certain optimizations being performed (read: many of blink's benchmarks) swing around from time to time, and we’ll sometimes see Chrome vary in size as the inliner decides to be more/less aggressive. Denoising this is being tracked in issue 849881.

Thanks @gbiv for taking a look.