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] Patch
Comment on attachment 347631 [details] Patch Attachment 347631 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8938508 New failing tests: http/tests/security/canvas-remote-read-remote-video-blocked-no-crossorigin.html http/tests/security/video-poster-cross-origin-crash2.html
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>
<rdar://problem/43595562>