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

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


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

Android Nexus6 WebView Perf

blink_perf.owp_storage - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

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

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

[DOMStorage] Enable onion soup codepath by dmurph@chromium.org
https://chromium.googlesource.com/chromium/src/+/80ce30280a48850aad465138b84fe209474733e8
Registry::RegisterBlob: 379.4 → 393.8 (+14.46)

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

Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

I'm not sure how this would increase the blob registration time - other than maybe we're competing for that event queue? Does blob registration run on the IPCTaskRunner?

+mek

What this is measuring is how long this one particular sync mojo call takes (i.e. how busy the browser process is at the time of trying to register the blob). Not sure how this would have an impact; looking at the actual changes is somewhat interesting though, as it seems that the time this takes has become a bit more bi-modal. While before there was only one peak in the distribution of times, now for at least -ipc, -tiny and -shm there is a second (lower!) peak, so a lot of registrations actually complete faster. The "main" peak just is apparently slightly slower enough to overall come out in the negative.

But agree that there is nothing here to worry about. Difference is tiny anyway.