New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

5.7%-452.3% regression in system_health.common_desktop at 548419:548615

Project Member Reported by primiano@chromium.org, Apr 9 2018 
See the link to graphs below.
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Apr 9 2018 

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

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


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

chromium-rel-mac11-pro
chromium-rel-win7-gpu-intel
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Apr 10 2018

Cc: taku...@chromium.org nedngu...@google.com xhw...@chromium.org rkaplow@chromium.org pmonette@chromium.org
Owner: nedngu...@google.com
Status: Assigned (was: Untriaged)
📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/11a5c3ecc40000

Disable test doubletap-to-jump-forwards-too-short on Win7 by takumif@chromium.org
https://chromium.googlesource.com/chromium/src/+/9e405e24c682904c03fcf620c388fb004b60ec0b

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

Add owners for load_library_perf_test by nednguyen@google.com
https://chromium.googlesource.com/chromium/src/+/dba633a1669bf5b75c4a5f7ffe2baef2be090fe9

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

Comment 4 by nednguyen@chromium.org, Apr 10 2018

Owner: pmonette@chromium.org

Comment 5 by xhw...@chromium.org, Apr 10 2018

Cc: -xhw...@chromium.org

Comment 6 by nednguyen@chromium.org, Apr 10 2018

Cc: -nedngu...@google.com

Comment 7 by pmonette@chromium.org, Apr 12 2018

Cc: engedy@chromium.org dgozman@chromium.org agl@chromium.org alph@chromium.org
 Issue 830671  has been merged into this issue.

Comment 8 by pmonette@chromium.org, Apr 12 2018

Cc: e...@chromium.org afakhry@chromium.org cjgrant@chromium.org ericwilligers@chromium.org roc...@chromium.org rkara...@yandex-team.ru vollick@chromium.org
 Issue 830677  has been merged into this issue.

Comment 9 by pmonette@chromium.org, Apr 12 2018 

 Issue 830685  has been merged into this issue.

Comment 10 by pmonette@chromium.org, Apr 12 2018

Blocking: 832286

Comment 11 by sullivan@google.com, May 3 2018

Cc: klausw@chromium.org wnwen@chromium.org hubbe@google.com sullivan@chromium.org bajones@chromium.org agrieve@chromium.org kbr@chromium.org ccameron@chromium.org billorr@chromium.org mbarbe...@chromium.org
 Issue 830652  has been merged into this issue.

Comment 12 by kbr@chromium.org, May 3 2018

Cc: -kbr@chromium.org

Comment 13 by wnwen@chromium.org, May 7 2018

Cc: -wnwen@chromium.org

Comment 14 by sullivan@chromium.org, Jul 20

Components: Speed>Metrics>SystemHealthRegressions

Comment 15 by pmonette@chromium.org, Jul 20

Status: WontFix (was: Assigned)
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.
►

Sign in to add a comment