Issue metadata
Sign in to add a comment
|
ScanImplModule takes a lot of CPU time in BrowserEfficiencyTest |
||||||||||||||||||||||||
Issue descriptionI captured an ETW trace while Chrome was running BrowserEfficiencyTest[1] like this: BrowserEfficiencyTest.exe -b chrome -i 2 -s FastScenario WikipediaUnitedStates UIforETW options were: Compress Trace, CPU sampling call stacks, Chrome developer, Identify Chrome CPU, Circular buffer tracing ETW trace: https://drive.google.com/file/d/1L6IYweF8NaOVTLV5KFgXeQoH5FHtvBjq/view?usp=sharing In this benchmark, Chrome is run twice. I looked at the second run of Chrome. The browser process is 7260. The top threads by CPU usage are IO thread (11612), UI thread (5184), and a thread that runs ScanImplModule (2332). ScanImplModule takes 1563 ms of CPU time, compared to browser and IO thread taking about 1650 ms each. That seems like a lot. This may be an artifact of tracing. I'm not sure. [1] https://github.com/MicrosoftEdge/BrowserEfficiencyTest/blob/master/Documentation/GetStarted.md
,
May 15 2018
There's no way for us to avoid the CPU work entirely, and the expense is largely due to looking up certificates for modules. This is part of third party module blocking, which is a long-standing effort to block third party software from injecting code into Chrome's processes. Since the actual module scanning isn't high priority (it just needs to eventually happen), we're actively working with the scheduler team to make sure we don't block more important work. To this end, we only scan modules after startup has completed, and a low priority background task queue. Regressions in input response and key performance metrics are things that we definitely care about, but the CPU work has to happen I'm afraid.
,
May 16 2018
Thanks for confirming that this is expected. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by brucedaw...@chromium.org
, May 15 2018