Re: [w3c/ServiceWorker] consider allowing multiple worker thread instances for a single registration (#756)

> The data about Cache API overhead is fascinating. Something we should all compete on driving down.

I don't know how chrome is implemented, but in gecko we have serialized reads of the Cache metadata during a `.match()`.  Its possible allowing concurrent read-write locking in sqlite would help here.  That was too big a change to prototype here, though.

> Regarding the addition to allow caching in-process, this is something we debated heavily inside the Chrome team regarding our memory-cache behavior (specifically) for images back in '12-'13. I think we'd love to be able to add something to a response that acts as a memory-cache control header.

Yea, it feels like we need something other than just the `cache-control` header.  We don't want a service worker to trigger this by accident with a pass-through fetch.  It should be a conscientious opt-in by the service worker.

> I'd love for us to explore how we can make an opt-in version of the multi-SW system possible for sites that want or need it. Opting into this treatment on an event-type basis seems reasonable to me, but as you mention, I think we should see how far we can get with sub-workers first.

Opt-in seems like a reasonable approach for fetch.  Not sure, though, if it addresses @aliams desire to move push handling into a separate process to better support "browser is closed" integration on desktop.

> Lastly, I guess I'm a little surprised the gains for multiple SW threads are so small. 10% ain't nothing, but it's in the range some strong optimisation in other subsystems can eek out in a few quarters.

Yea, its not a slam dunk.  Although, maybe it has a larger effect on mobile.  I wasn't able to really run my prototype stuff on firefox for android to test.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/756#issuecomment-242609755