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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg4omPtgoM


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

chromium-rel-win10

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

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

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

Hi shimazu@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 : shimazu
  Commit : 1ac68cf90fa046d3e9c1418aee7cd14b8ec38210
  Date   : Thu Apr 20 06:03:46 2017
  Subject: ServiceWorker: Use mojo's data pipe for respondWith(stream)

Bisect Details
  Configuration: winx64_10_perf_bisect
  Benchmark    : service_worker.service_worker_micro_benchmark
  Metric       : concurrent_10_response_50_percentile/concurrent_10_response_50_percentile
  Change       : 7.76% | 4.745 -> 5.11333333333

Revision             Result                    N
chromium@465881      4.745 +- 0.29             6      good
chromium@465901      4.745 +- 0.307327         6      good
chromium@465906      4.69583 +- 0.101837       6      good
chromium@465908      4.72833 +- 0.0716473      6      good
chromium@465909      5.1025 +- 0.0647109       6      bad       <--
chromium@465911      5.26 +- 0.92577           6      bad
chromium@465920      5.085 +- 0.0790569        6      bad
chromium@465958      5.11333 +- 0.110604       6      bad

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

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8981374504209148128

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5820477341171712


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

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

Suspected Commit
  Author : shimazu
  Commit : 1ac68cf90fa046d3e9c1418aee7cd14b8ec38210
  Date   : Thu Apr 20 06:03:46 2017
  Subject: ServiceWorker: Use mojo's data pipe for respondWith(stream)

Bisect Details
  Configuration: winx64_10_perf_bisect
  Benchmark    : service_worker.service_worker_micro_benchmark
  Metric       : concurrent_10_response_50_percentile/concurrent_10_response_50_percentile
  Change       : 8.94% | 4.745 -> 5.16916666667

Revision             Result                    N
chromium@465881      4.745 +- 0.431509         9      good
chromium@465901      4.67667 +- 0.06733        6      good
chromium@465906      4.68333 +- 0.0503322      6      good
chromium@465908      4.67083 +- 0.049202       6      good
chromium@465909      5.05333 +- 0.169362       6      bad       <--
chromium@465911      5.00417 +- 0.170502       6      bad
chromium@465920      5.01667 +- 0.155081       9      bad
chromium@465958      5.16917 +- 0.536909       6      bad

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

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8981374444505281088

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5852167757365248


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

shimazu@
Could you please investigate this performance regression?
How about the impact on the actual PWA sites? How many ICP messages are used for the mojo version FetchEvent.respondWith()? Is there any room for improvement?  etc..

 Issue 715854  has been merged into this issue.

IIUC, the test don't use the pipe because the workload creates the response in the fetch handler. 

I couldn't observe no significant change in UMA:
https://uma.googleplex.com/p/chrome/timeline_v2/?sid=440f3957392adc6e2b031f39a2b076d4

and only Mac (50%ile) looks effected on that range: https://chromeperf.appspot.com/report?sid=90ddb812cca93bda1299e1da498a3d5002b9e7f76c8c58c5711b26c0614f74be&start_rev=453946&end_rev=471044

However, the regression looks constant. It seems strange...

Ah, the patch also mojoified DispatcherFetchEvent. That might be the cause of this regression. The amount of regression is small and it doesn't seem happening on other platforms, so let me close this issue. 

c#11 was a bit wrong. The patch only added an argument of DispatchFetchEvent whcih is a callback interface to return the response. Difference of the patch is mojo::Binding<>::CreateInterfacePtrAndBind and passing the interface to DispatchFetchEvent, and it would not be surprising that these take 0.1ms.