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

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


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

android-nexus5
android-webview-nexus5X
chromium-rel-mac12
chromium-rel-win10

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8969256813350694432

=== Auto-CCing suspected CL author vmpstr@chromium.org ===

Hi vmpstr@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Vladimir Levin
  Commit : 87d148484da101cec9c59d89861c55643f15605d
  Date   : Wed Aug 30 20:45:14 2017
  Subject: images: Expose supported decode sizes from the JPEG decoder.

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : system_health.memory_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:cc:effective_size_avg/load_media/load_media_facebook_photos
  Change       : 24.89% | 27322212.0 -> 34123474.6667

Revision             Result                   N
chromium@498451      27322212 +- 455730       6      good
chromium@498542      27212303 +- 439405       6      good
chromium@498588      27824383 +- 2674575      6      good
chromium@498600      27804417 +- 2366277      6      good
chromium@498601      32714704 +- 0.0          6      bad       <--
chromium@498602      32306179 +- 5871946      9      bad
chromium@498603      33407825 +- 2401043      6      bad
chromium@498606      32306179 +- 5871946      9      bad
chromium@498611      33039419 +- 1925693      6      bad
chromium@498633      33061265 +- 1898191      6      bad
chromium@498815      34123475 +- 2442869      6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.media.facebook.photos system_health.memory_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8969256813350694432


For feedback, file a bug with component Speed>Bisection

Issue 762243 has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a8d5ae29ef798aecf0864d4d9cc232dfa213bd82

commit a8d5ae29ef798aecf0864d4d9cc232dfa213bd82
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Fri Sep 08 21:26:11 2017

images: Ensure not to waste space in JPEG decoded sizes calculation.

This patch changes the way we store decoded sizes in the JPEG decoder
to first create a reserved vector with just enough capacity, and then
move that into place. This should avoid wasted space.

For example, previously if max_numerator was 5, then capacity after
each push back would have been (assuming doubling memory for vector):
items:    1 2 3 4 5
capacity: 1 2 4 4 8

now, the capacity stays at 5 throughout.

R=chrishtr@chromium.org

Bug:  762198 
Change-Id: Ic6ba8fe4ba5038a48891226b5efb3754cbf05aed
Reviewed-on: https://chromium-review.googlesource.com/657879
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500682}
[modify] https://crrev.com/a8d5ae29ef798aecf0864d4d9cc232dfa213bd82/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp
[modify] https://crrev.com/a8d5ae29ef798aecf0864d4d9cc232dfa213bd82/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.h

All of the graphs (AFAICT) have recovered. Closing this.