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

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


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

linux-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1494398d240000

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

Roll AFDO from 69.0.3451.0_rc-r1 to 69.0.3453.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/f0739e861b6debbe47b69938999af5b3e51347b6
104.9 → 114 (+9.178)

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

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

WontFix'ing for two reasons:
- Looks like this regression is just 'undoing' the perf improvement from the AFDO roll in r564005
- We reverted to the 3450 profile because of  issue 851539 . When we start autorolling again, we're going to skip the 3453 profile. Jumping to a profile after 3453 might/might not "fix" this for us. If not, I'm sure I'll get another perf bug about it. :)

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.