📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14898dc0c40000

This might be related to crrev.com/c/875510 .

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/14898dc0c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14ec8c60c40000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/14ec8c60c40000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14ae5e60c40000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/14ae5e60c40000

Set Bug-Regression for better tracking in our triage process.

Did we learn anything here? pinpoint is failing.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15922538c40000

Thanks!

I don't understand why pinpoint is failing and which CL caused the regression, but I'm still suspecting http://crrev.com/c/875510. 
We may need to run bisect manually to check it.

Let me assign this issue to lucmult@ who is the owner of the CL.
lucmult@: do you think your CL can cause the regression?

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/15922538c40000

I've done some investigation related to memory consumption on  crbug.com/825815 .

Do you have more information if the site being tested actually uses Service Worker and Cache Storage API?

This CL changes that some initialization is deferred to when a Cache Storage is needed, before it would initialize when render process started, so there is a potential performance gain if Cache Storage isn't used.

Another difference is the use of Mojo for IPC instead of the legacy IPC system, but I'm not sure what is the expected impact of this on performance TBH.

Is there a way to revert this CL and re-test? It probably need this CL reverted too: crrev.com/c/907769

I think the loading.mobile tests use service worker + cache storage.

You can revert and re-test locally with a perf try bot: https://chromium.googlesource.com/chromium/src/+/lkcr/docs/speed/perf_trybots.md

I'm trying to understand why only "warm" would regress. This is the load after SW and cache storage has finished installing. If this regresses I'd expect "hot" to regress to, which is the load after V8 code cache has been populated.

Also, if only onload regressed, and page load metrics like FCP didn't regress, we probably don't really care.

The site regressing the onload is https://flipboard.com/topic/yoga. The site looks caching a core CSS and a core JavaScript on the install handler, and other resources are cached on the first load with a service worker (=warm).

FCP doesn't seem to have changed, so as falken said we don't need to care of it.
Graph:
https://chromeperf.appspot.com/report?sid=1849469558db2e20fee3ddb704134e66a5a9314ca721b81bcbd512dc6fb0973c&start_rev=544387&end_rev=549403

Let's mark this issue as WONTFIX.
lucmult: feel free to re-open this issue if you think we need to have further investigation. 

Thanks for the update, I'm fine with won't fix status.