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

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


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

mac-10_12_laptop_low_end-perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/142059a1e40000

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

cc: Rate limit raster metric queries. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/e898b99eac0cf5db379cf8c7e216d772095a7448
memory:chrome:all_processes:reported_by_os:system_memory:private_footprint_size: 1.41e+08 → 1.443e+08 (+3.287e+06)

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

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

There were a couple of timing changes that came with adding this metric that improved memory in some cases. For instance, I see [1] in the timeline before this change which caused an improvement that was countered with the change in #3. Overall any memory changes from adding this metric was unintended and the rate limiting just brings us back to where we were initially.

[1]: https://chromium.googlesource.com/chromium/src/+/da82bcce69bf5384435976a1945c9cb3270c5abb

 Issue 903119  has been merged into this issue.