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

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


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

chromium-rel-win7-gpu-intel

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1587e9b9440000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/1587e9b9440000

Fixed more Document leaks in Autofill by atimoxin@yandex-team.ru
https://chromium.googlesource.com/chromium/src/+/cb950738b5abba1e4a971becdf60fe855dfff21b

Wire-up the ThirdPartyBlocking group policy by pmonette@chromium.org
https://chromium.googlesource.com/chromium/src/+/a54726ff975e09efe95d241091a32954bdd58468

Revert "Wire-up the ThirdPartyBlocking group policy" by findit-for-me@appspot.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/05bc73c5307f415d77a8a5a6ba4d257f5b70ef99

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

reverting cb950738b5abba1e4a971becdf60fe855dfff21b (which landed as da22cad86e597d7f2bf2d4854ea832a23bacd022 ) did not do anything to restore the perf graph.

+Speed>Bisection to investigate what went wrong with the bisect job in #3. It clearly shows a jump in cb950738b5abba1e4a971becdf60fe855dfff21b.

This is bizarre, the Pinpoint bisect very clearly points to that cl, and exactly reproduces what was seen on the waterfall but as you point out, the revert has seemingly no effect.

+dtu any ideas on this?

I agree, it's a super weird result. Let's try some different ranges/metrics/bots and see if they're any different.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/106ab187440000

The only other things I can think of are:
* Something about the builds changed. But the builder bots haven't changed in months. If it was a change on the infrastructure side we wouldn't get such clean bisect results (same result as  issue 825109 ), and if it was a change in Chromium it would show up in the bisect as a culprit.
* The regression is caused by the interaction of two or more changes, or another change caused the same regression, so we need to revert another CL also to see the improvement.

 Issue 825109  has been merged into this issue.

Maybe the owners of the benchmark can provide other insight?
+kouhei, +ksakamoto

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

Roll src/third_party/catapult/ 7b53f088f..f73167a68 (1 commit) by catapult-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/320ac37b57c63feeac20bd169d80efdaa4c0a298

Get navigation info without using FrameLoader snapshots by dproy@chromium.org
https://chromium.googlesource.com/catapult/+/5d35a2c7122c1ac4a9a37e7743a19f628f25a38b

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

I was overzealous in marking this one as a duplicate. I looked into the traces from the last pinpoint job, and I don't think my CL is causing this regression. Usually all the other regressions due to that CL happens because we start using a different navigationStart event for computing ttfmp, but this is not the case here. 

I looked at the work that was happening between navigation start and fmp, and there is no clear culprit. A lot of unrelated events all just became slower. I attached screenshots of slice times between navStart and FMP before and after the regression.

I don't have enough context to debug this, so I'm marking this as available. 

Deleted: before-regression.png 49.9 KB

	before-regression.png 49.9 KB View Download

Deleted: after-regression.png 50.7 KB

	after-regression.png 50.7 KB View Download

Doesn't look like we'll get to the bottom of what happened here.