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

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


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

chromium-rel-win7-gpu-intel

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14c89992c40000

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

Adding fieldtrial config for the IncompatibleApplicationsWarning feature by pmonette@chromium.org
https://chromium.googlesource.com/chromium/src/+/7a86e22e588d7941bde54bdb4a8c58c23e502836

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

Closing this bug

Increased CPU time is totally expected from my feature. But the extra work is scheduled on a background thread and should not interfere with foreground work.

In addition, the extra work I am doing is a one time occurrence, that happens shortly after startup. A series of tasks is posted sequentially for each loaded DLL in the process (InspectModule() in module_info_win,h), and each tasks takes less than a second. It may seem long but keep in mind that this runs on a background task. Our metrics shows that the median amount of loaded DLLs for users in the wild is 120.

So unless we see more pref regressions that doesn't involve CPU time, this is working as intended.

Leaving WontFix because I think it's okay to accept this change in benchmark score with the explanation, but wanted to cc gab in case Lucky Luke can help with the task scheduling--it should be possible to schedule background work such that it doesn't affect a benchmark like this, right?

To clarify, this isn't a CPU benchmark, it's a layout benchmark measuring time to layout iframes from JavaScript. Source code is here: https://cs.chromium.org/chromium/src/third_party/blink/perf_tests/layout/Shapes/MultipleShapes.html

Yes it should be possible to more aggressively delay background work and not request layout when heavy background tasks are queued.

fdoray is working on this (tracked in issue 839110).

Let's make fixing this regression a goal of that work.