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

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


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

linux-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14ce8233240000

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

Optimize out work in CompositingLayerAssigner by chrishtr@chromium.org
https://chromium.googlesource.com/chromium/src/+/a9be49beca9893711aad3ffac2e00132d38c3bf8
1.087e+08 → 1.101e+08 (+1.403e+06)

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

Issue 856835 has been merged into this issue.

I synced to a point before this CL and the number of compositd layers created is
exactly the same.

The CL adds two bits to PaintLayer, but does not change its size. Even if it
did, it does not explain the memory use change.

I can only conclude that this CL somehow changes malloc patterns in a way
that increases memory.

Possibly the call to SetLostGroupedMapping does this.

SetLostGroupedMapping is not called on load of pinterest.

I don't think this bug is actionable unfortunately.