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

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


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

chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel

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

📍 Found significant differences after each of 4 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/12da027dc40000

Separate U2F specific logic in VirtualFidoDevice by hongjunchoi@chromium.org
https://chromium.googlesource.com/chromium/src/+/8dab8cfefbdc92721e825a466b1b249ef9842443

Add support for DebugID to vm memory maps by etienneb@chromium.org
https://chromium.googlesource.com/chromium/src/+/a1b0ba721f2c3efb3cca43b5bddb54715d2d2b42

Add support for DebugID for macOS. by erikchen@chromium.org
https://chromium.googlesource.com/chromium/src/+/0f2bbbfbc10159502a98aebd3e6cf2f44a145c6d

Fix LegacyNavigationManagerImpl::FinishGoToIndex. by eugenebut@google.com
https://chromium.googlesource.com/chromium/src/+/0796ec8ba7af1e8937b071528ff2aa7156860755

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

r552848 (Add support for DebugID for macOS) looks like the significant jump. Assigning to erikchen@ for further investigation.

 Issue 847564  has been merged into this issue.

The difference is that two more renderers are being spawned. One is a subframe. The other is not clear - maybe it's a prerenderer or something?

Over to OOPIF team. I'm particularly curious about this new, unlabeled renderer.

Deleted: Screen Shot 2018-06-14 at 1.37.02 PM.png 47.5 KB

	Screen Shot 2018-06-14 at 1.37.02 PM.png 47.5 KB View Download

Deleted: Screen Shot 2018-06-14 at 1.36.59 PM.png 61.7 KB

	Screen Shot 2018-06-14 at 1.36.59 PM.png 61.7 KB View Download

Could be the spare process?  I don't quite understand why there's a "Subframe:" label in the main frame's process in the first screen shot either-- otherwise it looks like one has Site Isolation with spare process enabled and the other doesn't.

Hmmm... I think this can be marked as WontFix with the same justification that was used for other bugs reporting increased memory usage after Site Isolation became the default:

    It is expected that site-per-process uses more memory - on average
    we expect to increase memory usage (e.g. as measured by
    Memory.Total.PrivateMemoryFootprint) by around 10%.

The extra renderer process mentioned in #c6 indeed seems to be the spare process which helps ensure that Site Isolation doesn't regress loading metrics (e.g. see http://go/site-isolation-performance#heading=h.ppv7vos32adj).