FWIW a couple of probably unrelated observations in Windows 7:
1. Firefox (multi-process mode): the site consumes several times more CPU and the same amount of memory.
2. Chrome 61: the site with ads removed (using uBlock-origin) consumes only ~50MB RAM vs 150-200MB and 10 times less CPU. Quite a difference.

CPU power -> shrike

Without disabling TurboBoost I get the following trough CPU readings:

Chromium 61.0.3137.0 Browser - 6%
Chromium Renderer - 38%
Chromium GPU - 10%

Safari Browser - 0%
Safari Renderer - ~3%

Quartz Debug shows that the entire web page contents are being redrawn very frequently. Safari, OTOH, has very few updates to very minimal portions of the page. So it seems that Chrome is performing much more repainting work than it needs to.

Link to reuters.com snapshot: https://drive.google.com/open?id=0BwcLL5PHtZQHMW53Mml1R0FKM2M

Moving to blink triage.

I am going to start with Paint, not sure where the culprit is.

This is another case where DevTools indicates we are not repainting anything much. We have several of these bug reports where Quartz Debug shows entire page changes but the renderer is not issuing repaints for very much at all. I can't help thinking this is an artifact or our compositing architecture on Mac.

Passing the bug to the compositor team in search of insight into why Quartz Debug shows whole page changes when in theory we are only re-rastering small portions of the screen.

I don't dispute that we are doing a lot of work in the renderer for some reason, probably invalidation checking and processing. It would be nice to have the costs line up more nicely with the output, but we're not going to try to optimize the system until we get to the new Slimming Paint V2 world. 

I'll take a look and see if I can see anything.

This still could be a paint issue in that layerization changes (or changes to layers) cause damage on screen (e.g. opacity changes or adding/destroying layers) without anything being invalidated directly.

Looking at quartz debug with "flash screen updates" on this reuters site, I see it flash the entire renderer for about 10s as the ad on the top animates.  In general, I see pretty much any renderer change on any page flash the entire renderer contents as being updated.  I'm not sure this is specific to this page.

ccameron, is this expected? Is this a dupe of the bug that you wanted to fix with better figuring out which quads and renderpasses were unchanged since the last frame?

I took a look at this, and the issue is that we have a RenderPassDrawQuad that has a non-zero sorting context ID. This kicks us out of using the CoreAnimation compositor, see:

https://cs.chromium.org/chromium/src/cc/output/ca_layer_overlay.cc?rcl=cf357e4d70c3f537994bbbce771b678bc6ef2d3e&l=88

I don't remember why this is the case, though. CoreAnimation's clipping ... mostly ... works -- (see issue 709510), but we are okay with relying on it.

Erik, do you remember the reason why we reject RPDQs with sorting context ids?

Uhh...trying to page this back in.

Could this be related to ordering issues? e.g. First we apply the filter effect, then we send to CoreAnimation. IIRC, Safari applies the filter effect as part of CA. 

Going back in history...
https://codereview.chromium.org/2205133003/diff/220001/cc/output/ca_layer_overlay.cc#newcode70

"""
Cause we're messing with the 3D transforms, we can only trust this to work when
we're just drawing layers on top of each other -- if we have to do
intersections, etc, in 3D space, we're hosed. So we'll need to fail if
sorting_context_id is 0.
"""

So, is this a WontFix "reuters shouldn't be using 3d css + sorting if they want to have fast performance" or is there work to be done here that can improve this case for this site and others?

I think we can relax some of the restrictions about sorting contexts.