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

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


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

chromium-rel-win10
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/155d6404c40000

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

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

Add SubmitFrameMissing mojo call for WebVR/WebXR by klausw@chromium.org
https://chromium.googlesource.com/chromium/src/+/f5bbb138786c2236059c0fa28eaecf1e9f1d4a9e

Revert "Add SubmitFrameMissing mojo call for WebVR/WebXR" by klausw@chromium.org
https://chromium.googlesource.com/chromium/src/+/4029d625bb7290835ef25c56b12275f6f2294bcf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1499dc72c40000

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

Delay the work of ModuleInspector by pmonette@chromium.org
https://chromium-review.googlesource.com/c/chromium/src/+/1008063/1

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

 Issue 830783  has been merged into this issue.

Adding the owner of the benchmark.

Can you help me figure out this regression? What is this benchmark testing exactly?

Thanks!

This tests Blobs / BlobStorage and IndexedDB. It seems like there is a matching speed up a little bit later in the graph, not sure why that happens.

I can't see the attached patch, so I don't know what it's doing.

The patch enables the ModuleDatabase. This is a class responsible for inspecting every DLL loaded into the process, in a background task. This is quite expansive in terms of CPU load, but the scheduler should be smart enough so that it doesn't impact important work. This doesn't touch blobs/ blobstorage nor IndexedDB.

But yeah, looking at the graph, it seems like there was a bug with the benchmark and something got fixed, possibly completely unrelated to my patch?

Let me know if you agree with me. This bug is blocking the launch of the feature to beta. thanks!

I'm guessing you're being scheduled during our perf test. After this patch everything gets way noisier, so I'm assuming it's because something else is running on a different thread with your ModuleDatabase project?

Yes this has been happening with a few other benchmarks. I'm trying to find a trace that shows it's happening here, but I'm getting 500 errors for some reason.

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.