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

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


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

Android Nexus5 Perf
Android Nexus6 WebView Perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1606e69a640000

📍 Found significant differences after each of 5 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/1606e69a640000

Roll AFDO from 70.0.3529.0_rc-r1 to 70.0.3530.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/9f547654633778c99e48754b772b75d088f6280a
273.9 → 284.1 (+10.19)

Set an expiry date for unused histograms (NaCl.*) by gayane@chromium.org
https://chromium.googlesource.com/chromium/src/+/b5e045e50ff8d784be320df6308ef11a610cbdfb
354.7 → 1.326e+04 (+1.29e+04)

Reset touch action at TouchActionFilter's constructor by xidachen@chromium.org
https://chromium.googlesource.com/chromium/src/+/0d326b48bd894605b4e41e22f6f085af7c12274b
1.326e+04 → 288.3 (-1.297e+04)

Split placeholder image load checks and enables by rajendrant@chromium.org
https://chromium.googlesource.com/chromium/src/+/037dd7049bb4a1eddc14bc7d5343da4aa95414a3
287.5 → 1032 (+744.6)

[fuchsia] Implement Frame::GetVisibleEntry() API method. by kmarshall@chromium.org
https://chromium.googlesource.com/chromium/src/+/489df11cf0900cf2a1104fdec2efc09f8508f9b0
1032 → 283.5 (-748.6)

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

Don't think I'm the culprit.

Reassigning to the CL creator whose change affects Blink.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13970cf1640000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/13970cf1640000

[blink-gen-property-trees] Optimize VisualViewport update by bokan@chromium.org
https://chromium.googlesource.com/chromium/src/+/02246605274d8c4e7569e317b1dd95bf74caf263
0.5226 → 0.4465 (-0.07615)

Roll AFDO from 70.0.3529.0_rc-r1 to 70.0.3530.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/9f547654633778c99e48754b772b75d088f6280a
0.4369 → 0.3972 (-0.03972)

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

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

Assigning to gbiv@ to take a look from the perspective of roll AFDO changes.

My CL "Split placeholder image load checks and enables" is only a refactor and likely to not cause issues. The CL was also reverted immediately (in 1.5 hours) for code formatting issues and landed 6 days later.
https://chromium.googlesource.com/chromium/src/+/037dd7049bb4a1eddc14bc7d5343da4aa95414a3

tl;dr: decode-png has recovered, and hit-test-lots-of-layers is just AFDO taking away an improvement it gave to us a few weeks ago. Doesn't look like this noise is super persistent in either case, so I'm wontfixing this.

More words:

`blink_perf.image_decoder / decode-png` is almost definitely AFDO; it's recovered since, and the CL range on which it recovered includes another AFDO roll (r586612).

As for `blink_perf.events / hit-test-lots-of-layers`, looks like the AFDO roll at r578948 gave us quite a noticeable perf improvement, then the roll in r585229 happened and we lost (some of) said improvement (the big drop is  issue 875991 , which is unrelated to AFDO).

I don't see any obvious/consistent AFDO-induced swings in the `.events` benchmarks, and this is the only notable jump I see in the history of `.image_decoder`. So, I don't think there's much to be done here on the AFDO front.

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.