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

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


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

mac-10_12_laptop_low_end-perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/143df37d940000

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

base: Improve base::File::Flush() on macOS and iOS. by pwnall@chromium.org
https://chromium.googlesource.com/chromium/src/+/90c2ed99a4bd5d9fa949d9ba14b37c3c29b0d9fb
blob-perf-files: 791.1 → 3377 (+2586)

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

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

+cc other IndexedDB folks, for FYI

We expected regressions, as described in the CL message, so marking this as WontFix.

This pinpoint is a bit of a relief to me -- we now know that the change works, and that I/O is not so dominated by IPC overhead that it wouldn't matter at all. 

That being said, blink_perf.owp_storage is a bit of a micro-benchmark, so the number shouldn't be indicative of the real-life regression. We should use Forklift to see how we're doing.

As said in person, the worst regression here is a 360% regression on blob-perf-files, which while expected is very unfortunate as the blob system really doesn't need to be flushing as aggressive as this change made things do.