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

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


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

android-webview-nexus5X

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16b90c84a40000

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

[PE] Improve background image painting by schenney@chromium.org
https://chromium.googlesource.com/chromium/src/+/ae49f5caf2943049acab4abe802e82c8dc001184
9.714e+07 → 9.751e+07 (+3.633e+05)

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

I don't see how this is actionable. The patch in question made a stack-allocated object a little bigger, but otherwise should not have resulted in any memory changes unless it now fixes something we weren't aware was broken.

Looking at what I believe is the test page, there are several background images and we may be now missing an optimization on this platform for some reason. On the other hand, this patch fixes several bugs, including some for Google properties, and now generates much more correct results for background images from sprite maps, particularly under zoom or high dpi.

I don't see why Webview would regress and not Chrome on Android.

Who owns this benchmark?

+perzju@ is likely to have thoughts here.

I don't know why we would look at the average size of allocated objects.

The size of the regression (~ 500 KiB) isn't huge, but let's have a look in case we can find something.

> I don't see why Webview would regress and not Chrome on Android.

Actually Android also seems to regress around the same CL, but the metric is a bit more noisy there:
https://chromeperf.appspot.com/report?sid=dc3b0fd3eb95ab13f29215b2b54634690324a08b4f99f7da5e064ea06a8ac676&rev=571564

Also, it looks like soon after this CL another ~500KiB regression occurred, bringing us closed to a full 1MiB and something a bit more concerning.

I'll kick-off a wider pinpoint job to see if we can find that second jump.

Meanwhile, have you tried looking at a couple of traces to identify where the memory increase is coming from?

before:
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_media_dailymotion_2018-06-29_18-33-31_94104.html

after:
https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/load_media_dailymotion_2018-06-30_00-41-59_28251.html

> I don't know why we would look at the average size of allocated objects.

We're not looking at the average size of objects. This metric reports the sum of all allocated objects.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/103087b2a40000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/103087b2a40000

Buildbucket says the build completed successfully, but Pinpoint can't find the isolate hash.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/157788b8a40000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/157788b8a40000

Buildbucket says the build completed successfully, but Pinpoint can't find the isolate hash.

+simonhatch, pinpoint keeps failing.

Blocking on  crbug.com/862654  - Pinpoint failure finding isolate hash

Oops, of course.
allocated_objects_size_avg is a slightly confusing name - it's averaging across runs, not within one run.

 Issue 862654  is fixed. I'm re-running these jobs.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/13d5b8a1a40000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/13d5b8a1a40000

[PE] Improve background image painting by schenney@chromium.org
https://chromium.googlesource.com/chromium/src/+/ae49f5caf2943049acab4abe802e82c8dc001184
9.697e+07 → 9.753e+07 (+5.605e+05)

Turn on OOP Raster on android bots by enne@chromium.org
https://chromium.googlesource.com/chromium/src/+/d82c4fabc5cc6cbe6b475186ed9fa0216980e533
9.759e+07 → 9.818e+07 (+5.825e+05)

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

This is almost certainly my change.  Khushal has landed a couple of changes which should make this recover, although the system_health.memory_mobile bots don't seem to have caught up to them yet.