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

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


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

android-nexus5
android-nexus6
android-nexus7v2
android-one
android-webview-nexus5X
android-webview-nexus6
chromium-rel-mac-retina
chromium-rel-mac11
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
linux-release
win-high-dpi

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8964270161089456432

=== Auto-CCing suspected CL author mek@chromium.org ===

Hi mek@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Marijn Kruisselbrink
  Commit : df51989616e170eef04e72779d0d7e5c3ee5980a
  Date   : Thu Oct 26 19:52:57 2017
  Subject: Turn mojo blobs on by default.

Bisect Details
  Configuration: mac_10_12_mini_8gb_perf_bisect
  Benchmark    : blink_perf.owp_storage
  Metric       : blob-build-and-read-immediately/blob-build-and-read-immediately
  Change       : 28.01% | 355.914916667 -> 455.592333333

Revision             Result                  N
chromium@511883      355.915 +- 8.5972       6      good
chromium@511922      355.49 +- 3.89024       6      good
chromium@511927      355.693 +- 6.81159      6      good
chromium@511928      359.483 +- 5.91439      6      good
chromium@511929      458.391 +- 5.98145      6      bad       <--
chromium@511930      461.909 +- 14.1365      6      bad
chromium@511932      461.098 +- 20.2314      6      bad
chromium@511941      459.593 +- 6.47628      6      bad
chromium@511960      455.357 +- 4.16995      6      bad
chromium@512036      455.592 +- 6.83574      6      bad

Please refer to the following doc on diagnosing blink_perf regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.owp_storage

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8964270161089456432


For feedback, file a bug with component Speed>Bisection

Wow this is quite the perf regression! hm. I wonder why? I'm wondering if it's only for large blobs.

We should run this locally to see which size of blobs this is regressing.

Yeah, running this locally was going to be my next step. What does this test actually do? Is it just some artificial benchmark doing something with blobs?

It's doing one of three things:

* Creating a blob, reading it, then repeat
* Creating a lot of blobs, reading them all sequentially
* Creating a lot of blobs, then reading them all at the same time.

 Issue 780215  has been merged into this issue.

 Issue 780218  has been merged into this issue.

Issue 780243 has been merged into this issue.

The memory regressions that got merged into this (btw, why do completely different types of regressions get merged into one bug? That makes triaging/following up/making sure not to miss something so much harder...) are weird. At least the worst regression is a quite significant 11.6%/5.7 MiB regression, except that is in CC memory. And I'm not sure how the blob system could be effecting anything CC related...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9a0e42a43b3a5bdcb81d8fb4617537156631d032

commit 9a0e42a43b3a5bdcb81d8fb4617537156631d032
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Fri Nov 03 18:18:50 2017

Add Registry::RegisterBlob trace event to mojo codepath.

This trace event is used in perf tests, so we should have it in the mojo
codepath to be able to compare to the old ipc codepath.

Bug:  779798 
Change-Id: I49e07453ffaa2d3b6a53b81b192b04c96dabd9f8
Reviewed-on: https://chromium-review.googlesource.com/754042
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Daniel Murphy <dmurph@chromium.org>
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513840}
[modify] https://crrev.com/9a0e42a43b3a5bdcb81d8fb4617537156631d032/third_party/WebKit/Source/platform/blob/BlobData.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1c46160b02845c10ec451e05b99101f6a736e506

commit 1c46160b02845c10ec451e05b99101f6a736e506
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Fri Nov 03 19:18:08 2017

Cache thread-local BlobRegistryPtr.

This should resolve some (but not all) of the performance regressions shown by
the blob perf tests.

Bug:  779798 
Change-Id: Ia871920faee04557be6fa6f1edfa4fa2dcbb323d
Reviewed-on: https://chromium-review.googlesource.com/753970
Reviewed-by: Daniel Murphy <dmurph@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513866}
[modify] https://crrev.com/1c46160b02845c10ec451e05b99101f6a736e506/third_party/WebKit/Source/platform/blob/BlobData.cpp

 Issue 781796  has been merged into this issue.

Apologies, applied the wrong component in bulk.

I don't think there is much left here to fix. There still is a small performance regression in some of these benchmark, but I think other changes made possible by this change will make things much better, eliminating most if not all of those regressions.

Specifically about the blink_perf.owp_storage / Registry::RegisterBlob regression (which is relatively speaking the worst regression, almost doubling in time), in absolute numbers even that regression isn't that much. Eventually I hope to be able to make that IPC async, which would get rid of most of the delay there. But even then, both the IPC and mojo codepaths are blocking IPCs, so I'd expect similar performance. Looking at profiling data for that specific bit of code though, the mojo codepath spents a significant amount of time (~33%) in mojo::CreateMessagePipe (to create the Blob and BlobBytesProvider message pipes). Other than that the two codepaths are nearly identical (sending a single sync IPC, which does more or less the same work). Not sure there is much that can be done about that. (it also spends ~10% of its time in PostTask, which shows that the whole thing is just so fast anyway that while relatively the new codepath might be a bit slower, in absolute numbers there isn't much of a regression).

Setting Internals>Services>Storage to all children of issue 611935