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

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


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

chromium-rel-win7-gpu-intel
chromium-rel-win8-dual

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

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

Enable CodeCacheAfterExecute by default. by mythria@chromium.org
https://chromium.googlesource.com/chromium/src/+/4043418267791fb7e8f89150f3dcfbadb5eeef16

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

The regressions on loading metrics on warm runs is expected, since we serialize more code during the warm runs. We would have see an improvement in hot runs, but loading.desktop does not have a hot run. The results from v8.runtimestats.top_25 on hot runs show a reduction in the startup time ~5%.

I am not sure about regressions in scheduler.tough_scheduling_cases in queueing_duration and mean_input_event_latnecy. I am starting a bisect on these metrics to be sure they are caused by CodeCacheAfterExecute.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11d2cb14440000

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

Disable runtime feature CompositeOpaqueFixedPosition by yigu@chromium.org
https://chromium.googlesource.com/chromium/src/+/5770b54a09c563cf56d7d2aaf7cdda80c59e1be1

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

The regression on input event latency is also expected as we stop compositing fixed position which bumps the scroll to main thread on the tested low dpi devices.