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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6ufx9ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6uKkrgoM


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

chromium-rel-mac-hdd

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

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

Hi hajimehoshi@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Remove duplication of encoded image data
Author  : hajimehoshi
Commit description:
  
Now there are at least two encoded image data: one is in Image/ImageResource as
SharedBuffer and the other is in DeferredImageDecoder as SkRWBuffer. This CL
removes former when possible (non-icon bitmaps), and generate the SharedBuffer
from the SkRWBuffer if needed.

Design Doc: https://docs.google.com/document/d/1v0yTAZ6wkqX2U_M6BNIGUJpM1s0TIw1VsqpxoL7aciY/edit?usp=sharing

BUG= 618623 
TEST=blink_platform_unittests --gtest_filter=BitmapImageTest.*:ImageDecoderTest.*

Review-Url: https://codereview.chromium.org/2054643003
Cr-Commit-Position: refs/heads/master@{#406238}
Commit  : 36f4eb81d4a791a8e3dfea4ba2418465d30bcc90
Date    : Tue Jul 19 10:02:08 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@406231  19660.8  17947.8  5  good
chromium@406236  21299.2  19515.2  5  good
chromium@406237  19660.8  17947.8  5  good
chromium@406238  462029   17947.8  5  bad    <--
chromium@406240  469402   15216.0  5  bad
chromium@406249  475955   1831.79  5  bad
chromium@406267  462029   17947.8  5  bad

Bisect job ran on: mac_hdd_perf_bisect
Bug ID: 631068

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests system_health.memory_desktop
Test Metric: load_news-memory:chrome:all_processes:reported_by_chrome:discardable:effective_size_avg/load_news_nytimes
Relative Change: 2250.00%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_hdd_perf_bisect/builds/665
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9006151892507556160


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5965473808646144

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

I think, https://chromium.googlesource.com/chromium/src/+/0a7a65b967c020c7380cba3488b8316b56708ed7 affected:
- load:social:twitter
- browse:social:twitter

So ChromiumPerf/chromium-rel-mac-hdd/system_health.memory_desktop / memory:chrome:renderer_processes:reported_by_chrome:gpu:effective_size_avg / load_social / load_social_twitter is not caused by hoshi's patch, I think.

I'm now investigating nytimes' regression.

I looked at discardable:effective_size_avg/load_news_nytimes and discardable:locked_size_avg/load_news_nytimes.

So, I think,
- discardable:effective_size_avg => regressed.
- discardable:locked_size_avg => not regressed.

This means, discardable:unlocked_size_avg increased, i.e. not regression. It is possible to purge unlocked discardable memory if we need.