RenderLayerCompositor::updateCompositingPolicy() is called very often (called from RenderLayerCompositor::cacheAcceleratedCompositingFlags()) and it uses WTF::memoryFootprint() to decide the current compositing policy. Getting the memory footprint is an expensive operation in Linux (and I suspect other non-cocoa ports too), causing an excessive CPU usage. This caused the WPE and GTK+ unit test /webkit/WebKitWebContext/uri-scheme to start timing out in the bots, because the test expects things to happen fast and that's no longer the case. We could reduce the CPU usage a lot by not trying to update the policy when not in accelerated compositing mode. We will need a solution for the AC mode, though.
Created attachment 347631 [details]
Comment on attachment 347631 [details]
Attachment 347631 [details] did not pass win-ews (win):
New failing tests:
Created attachment 347750 [details]
Archive of layout-test-results from ews202 for win-future
The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews202 Port: win-future Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit
Committed r235162: <https://trac.webkit.org/changeset/235162>