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

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


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

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

system_health.common_desktop - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

memory.desktop - Benchmark documentation link:
  None

system_health.memory_desktop - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11e874c5640000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/104dddc5640000

Pinpoint job in comment 2 seemed to find something, but was unclear to me. I've kicked off a slightly wider bisect to get more data points.

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/104dddc5640000

Turn on OOP Raster on mac bots by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/ee35f329c8e615505326a3b4df9ae4b7764037ae
1.019e+08 → 1.058e+08 (+3.98e+06)

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1478e425640000

There are 3 regressions duped into this bug. 

1) memory:chrome:all_processes:reported_by_chrome:cc:effective_size_avg/load_tools/load_tools_drive

2) timeToFirstPaint_avg/browse_social/browse_social_facebook_infinite_scroll

3) 	memory:chrome:all_processes:reported_by_os:system_memory:private_footprint_size_avg/TrivialGifPageSharedPageState

The first one, which is for cc:effective_size_avg is for resource memory from tiles. There are different sets of tiles in the before/after case, which is expected since OOP raster changes the speed at which we rasterize tiles in the renderer so can affect scheduling of raster work and how much we are able to pre-paint etc. So that's a WontFix. I'll look through the rest.

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/1478e425640000

Turn on OOP Raster on mac bots by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/ee35f329c8e615505326a3b4df9ae4b7764037ae
9.679e+07 → 9.096e+07 (-5.834e+06)

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

The timeToFirstPaint_avg regression is the same root cause as  issue 854416 . With OOP raster the GPU swap which marks firstPaint is behind a raster task which runs for ~150ms compiling shaders while with GPU this work is constantly pre-empted to allow the display swap. The disk caching of shaders should help in avoiding these scenarios in the common case of starting with a warm cache. So this is also a WontFix.

The odd thing is that I didn't see any call to look up from the disk cache from skia during this task. Maybe the disk cache is being disabled in skia, I'll need to confirm this.

So the reason why we're not hitting the disk cache is because we downgrade the GL version advertised to skia to 3.2 while it requires at least 4.1 in skia. That's being tracked in  issue 867187 .

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/100ee94d640000

I'm not completely sure what to make of the 	memory:chrome:all_processes:reported_by_os:system_memory:private_footprint_size_avg/TrivialGifPageSharedPageState. Looking at the traces, there is a 2.5M regression in total private memory footprint across all processes (went from 96 -> 98.5). I don't see a change in memory from any of the sub-components that could account for this. There is a minor change in browser memory (40.8 -> 41.3) which should be unaffected by this feature.

There is an increase in GPU process private memory footprint (25.7 -> 28.3) which I could see being related. But enne@ pointed that we had an improvement on another case in this benchmark (TrivialAnimationPageSharedPageState) which is also unexpected from this change. I've started a bisect to confirm that it was this change.

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/100ee94d640000

Turn on OOP Raster on mac bots by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/ee35f329c8e615505326a3b4df9ae4b7764037ae
9.67e+07 → 9.061e+07 (-6.089e+06)

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

So TrivialGifPageSharedPageState regressed by 4M and improved by 6M, and I don't see any change in subcategories that would explain either of these changes. I think oop-r is changing timing of when things run in the GPU process enough to ignore changes of this magnitude.