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

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


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

android-nexus6

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/128fe1ec440000

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

Rate Limit RenderFrameMetadataObserver by jonross@chromium.org
https://chromium.googlesource.com/chromium/src/+/13c8861d8d297b2dcb54b7a68eda0d09a6ea2c0e

Media remoting cleanup: Remove codes that support encrypted contents. by xjz@chromium.org
https://chromium.googlesource.com/chromium/src/+/acebf6504d2e1d1b051f6f8e9fb128d4c7e404c2

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

xjz's work should not have affected Android. That, and it was code removal that should have only improved start-up latency on desktop.

So, let's start looking at the other change first. :)

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14a21052440000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1290fd42440000

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

Rate Limit RenderFrameMetadataObserver by jonross@chromium.org
https://chromium.googlesource.com/chromium/src/+/13c8861d8d297b2dcb54b7a68eda0d09a6ea2c0e

Media remoting cleanup: Remove codes that support encrypted contents. by xjz@chromium.org
https://chromium.googlesource.com/chromium/src/+/acebf6504d2e1d1b051f6f8e9fb128d4c7e404c2

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

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

Rate Limit RenderFrameMetadataObserver by jonross@chromium.org
https://chromium.googlesource.com/chromium/src/+/13c8861d8d297b2dcb54b7a68eda0d09a6ea2c0e

Media remoting cleanup: Remove codes that support encrypted contents. by xjz@chromium.org
https://chromium.googlesource.com/chromium/src/+/acebf6504d2e1d1b051f6f8e9fb128d4c7e404c2

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

Pinpoint keeps re-assigning. Assigning back to jonross@, per comment 4.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14e69552440000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14e69552440000

My change was removing PostTasks and IPCs in prod. It was designed to fix a separate performance regression.

I've re-ran the pinpoint with a change where the RenderFrameMetadataObserver execution is disabled. It found no difference.

I'm re-assigning with xjz@ to investigate if their change actually did affect this. If you run a pinpoint and also find no difference I would recommend running a bisect, possibly with a larger range of changes.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1196d112440000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/1196d112440000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12a2f8da440000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14eed5a6440000

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

Not for Review - Pinpoint revert RFMO rate limit by jonross@chromium.org
https://chromium-review.googlesource.com/c/chromium/src/+/956409/2

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

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

Not for Review - Pinpoint revert RFMO rate limit by jonross@chromium.org
https://chromium-review.googlesource.com/c/chromium/src/+/956409/2

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

I'm sending this back for triage.

Looking at the traces the jump in memory is occurring in the Browser process, whereas my change affected the Renderer process.

I've also ran 3 different Pinpoints each of which showed no difference
  - Disabling the logic changes of my patch, so my code didn't run
  - Reverting the data structure change, in case that caused it
  - Reverting the entire change

The third graphs also show this chart as very flaky with my change in range of those flakes.

The first two graphs all have a large spike up at the range of my patch, but afterwards return to being flaky.

The other weird thing: This is an Android regression, but xjz's change could only have affected the desktop platforms.

It feels like there is something external (i.e., host configuration, or data center environment) going on here.

+dtu, another bisect result needing investigation.

Looks like the full revert jobs failed because the patch didn't apply cleanly. I'm going to re-try the Pinpoint jobs with a rebased revert. (https://chromium-review.googlesource.com/c/chromium/src/+/965404)

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12c34c7e440000

xjz's change looks like it caused a very minor improvement in memory on Android.

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

Revert "Rate Limit RenderFrameMetadataObserver" by dtu@chromium.org
https://chromium-review.googlesource.com/c/chromium/src/+/965404/2

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

Reassigning to jonross since the pinpoint run in #25 reproduces the memory regression the bisect originally caught.

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

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/16e68ab8a40000

This regression was only seen on the android-nexus6 variant. Which has since become deprecated and removed.

This regression was also seen before a lot of work was done on Viz and RenderFrameMetadata observer on Android.

Since the original regression the charts did recover before taking the bots offline.

I haven't seen this regression on other androids.

I'm marking as Wont Fix do to the only bot showing the regression being gone.