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

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


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

chromium-rel-win7-dual
chromium-rel-win7-gpu-nvidia
chromium-rel-win8-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15e7cc46c40000

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

Wait until after startup to inspect loaded modules by pmonette@chromium.org
https://chromium.googlesource.com/chromium/src/+/ab3074084f4f13af27a18b47c52fbe6968b7a425

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.