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

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


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

Win 7 Perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14974aa2e40000

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

Disallow libjpeg_turbo downscaling of images with non-whole MCUs. by andrescj@chromium.org
https://chromium.googlesource.com/chromium/src/+/8b9172a61f4e507b2eef30b2af438d2c19c0992d
memory:chrome:all_processes:reported_by_chrome:skia:effective_size: 4.855e+05 → 1.689e+06 (+1.203e+06)

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

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

 Issue 897114  has been merged into this issue.

 Issue 897112  has been merged into this issue.

The memory regression is expected because my CL effectively (and deliberately) negates some of the benefits of https://chromium-review.googlesource.com/c/chromium/src/+/1102025: some JPEG images need to be decoded to full size instead of a smaller size in order to avoid artifacts as described in  https://crbug.com/890745 .

To investigate this, I effectively reverted both:

- https://chromium-review.googlesource.com/c/chromium/src/+/1274845 (my CL)
- https://chromium-review.googlesource.com/c/chromium/src/+/1102025 (the earlier CL negated by mine)

Then, I ran a system_health.memory_desktop Pinpoint job using this revert for the bots and stories listed in https://chromeperf.appspot.com/group_report?bug_id=897115. The results for memory:chrome:all_processes:reported_by_chrome:skia:effective_size are:

Bot                              Story                                        Diff.
====================================================================================
Win 7 Perf                       browse:news:flipboard                        -59.7%
Win 7 Perf                       multitab:misc:typical24                      + 3.8%
Win 7 Perf                       browse:social:twitter:infinite:scroll:2018   + 2.3%
mac-10_13_laptop_high_end-perf   load:news:nytimes:2018                       + 0.1%
mac-10_13_laptop_high_end-perf   browse:news:cnn:2018                         + 0.7%

A positive % indicates a regression with respect to the revert, but none of the regressions were marked as significant.

Furthermore, with respect to the revert:

- For Win 7 Perf, the difference for memory:chrome:all_processes:reported_by_chrome:skia:effective_size is -1.5%.
- For mac-10_13_laptop_high_end-perf, the difference for memory:chrome:all_processes:reported_by_chrome:skia:effective_size is -2.0%.

So, this suggests that at worst, my new CL simply takes us to the state before the CL that triggered the artifacts in  https://crbug.com/890745 .

There were other regressions marked as significant with respect to the revert, but none were large percentage-wise, so I decided not to explore them further. Here they are for Win 7 Perf:

memory:chrome:all_processes:reported_by_chrome:net:effective_size (+0.0%)
memory:chrome:all_processes:reported_by_chrome:peak_size (+1.5%)
memory:chrome:all_processes:reported_by_chrome:v8:allocated_by_malloc:peak_size (+1.5%)
memory:chrome:all_processes:reported_by_chrome:v8:peak_size (+1.5%)
memory:chrome:browser_process:reported_by_chrome:malloc:effective_size (+0.3%)
memory:chrome:browser_process:reported_by_chrome:skia:effective_size (+1.6%)
memory:chrome:renderer_processes:reported_by_chrome:peak_size (+1.5%)
memory:chrome:renderer_processes:reported_by_chrome:v8:allocated_by_malloc:peak_size (+1.5%)
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:code_space:allocated_objects_size (+1.6%)
memory:chrome:renderer_processes:reported_by_chrome:v8:peak_size (+1.5%)
memory:chrome:unknown_processes:reported_by_os:system_memory:private_footprint_size (+0.0%)

And for mac-10_13_laptop_high_end-perf:

memory:chrome:all_processes:reported_by_chrome:v8:heap:large_object_space:allocated_objects_size (+1.6%)
memory:chrome:renderer_processes:reported_by_chrome:v8:heap:large_object_space:effective_size (+1.5%)

For reference:

CL with the reverts: https://chromium-review.googlesource.com/c/chromium/src/+/1305495
Win 7 Perf all results: https://pinpoint-dot-chromeperf.appspot.com/job/14a5150ee40000
Win 7 Perf browse:news:flipboard results: https://pinpoint-dot-chromeperf.appspot.com/job/156b5b91e40000
Win 7 Perf multitab:misc:typical24 results: https://pinpoint-dot-chromeperf.appspot.com/job/11589286e40000
Win 7 Perf browse:social:twitter:infinite:scroll:2018 results: https://pinpoint-dot-chromeperf.appspot.com/job/14259086e40000
mac-10_13_laptop_high_end-perf all results: https://pinpoint-dot-chromeperf.appspot.com/job/127ff42ee40000

Post-closing note: just realized that regression significance in Results2 tends to change between refreshes. After refreshing the results for Win 7 Perf and mac-10_13_laptop_high_end-perf, I still didn't notice any regressions worth pursuing.