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

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


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

chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-nvidia

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11bfe31c040000

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

Add a Feature and field trial for SavePreviousDocumentResources experiment
By japhet@chromium.org · Fri Dec 01 17:09:24 2017
chromium @ 82a20b628c47a5c465af8f035935ecdbf3ce1689

Send proxy configuration over Mojo pipe in Chrome.
By mmenke@chromium.org · Fri Dec 01 19:00:50 2017
chromium @ d0d0d0508a541932ce4e43dfdeec1eb6dacf9edf

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

[+dmurph]:  What does this test actually do?

I'm pretty sketpical that a proxy configuration change only affected a single test (Either a bunch of tests that use proxies should have reverted, or none of them should have, unless this test does uniquely weird proxy stuff)

Hi!

This graph measures how long it takes to register a blob, which involves sending over metadata (and sometimes data) about the blob to the browser. This will create 1 or 2 message pipes. +mek for mojo-specific knowledge here, I'm guessing this change makes creating message pipes slower?

This change has nothing to do with creating message pipes.  I moved the service to get the network proxy configuration from the IO thread over to the UI thread, and made it use a mojo pipe to pass the information over to the IO thread.

We may be able to run it on another thread instead of the UI thread, though it actually does its blocking file IO off thread, anyways, so I'm really not seeing how it could affect just this test.  It should, at most, just add a little extra Mojo overhead, and possibly an extra thread hop (UI->UI->IO instead of UI->IO, because it has two halves that used to be run on different threads, at least on Linux - not sure if Android gets an extra hop, too).

A little extra overhead due to using mojo, that is, not a little extra overheard to using Mojo in general (Since the change is purely in adding a mojo consumer, not a change to mojo itself)

I think this is just a case of the owp_storage test in question doing so little work that any change in overhead anywhere in the system can cause seemingly significant changes. The metric itself just measures how long a single sync mojo call takes, so any change in how busy the browser process is could have some impact. I don't think there is anything to worry about here.