importScripts and sub-optimal loading performance

[Yoav Weiss]

Hey folks,

Dan from Wix (CCed) brought to my attention the fact that Chromium's `importScripts` implementation is absurdly slow, as it loads and executes the scripts synchronously, resulting in a waterfall cascade when importing more than one script, making script import latency- and execution-bound. So if developers are writing multiple worker scripts (which we should encourage, as they are easier to cache), they would pay an extra RTT for every script they import beyond the first one. That's bad.

It seems like this is how the feature is specified, but the spec should be fixed, and Firefox is already implementing the faster, async-loading, behavior.

Looking at the code, fixing it doesn't seem like a huge project.

Can we make that happen? Anyone with spare cycles that can take on this high-impact change?

Cheers :)

Yoav

[Hiroki Nakagawa]

Hi Yoav,

I agree this seems to have high-impact on applications that heavily use importScripts(), and it's nice to fix it.

As I replied in the crbug, this probably needs some architectural changes in worker/loader implementation that take time. The worker thread should be blocked until all scripts are fetched, but I'm not clearly sure how to implement it yet (fetching scripts in background threads and waiting for completion of them using base::WaitableEvent?). I roughly estimate this work will take 1+ quarter for investigation, designing, implementation, and testing on all worker types.

[Kinuko Yasuda]

Thanks Yoav, interesting to know that the spec's going to be changed for this.  I'd like to talk with people to see how we might tackle this.  (I'll likely would like us to quickly try & see if we can get the rough estimates of the impact.  We could probably add some UMAs and Mozilla may have some numbers too?  Either way I can imagine this could have impacts.

[Yoav Weiss]

On Wed, May 27, 2020 at 12:58 AM Kinuko Yasuda <kin...@google.com> wrote:

Thanks Yoav, interesting to know that the spec's going to be changed for this.  I'd like to talk with people to see how we might tackle this.  (I'll likely would like us to quickly try & see if we can get the rough estimates of the impact.  We could probably add some UMAs and Mozilla may have some numbers too?  Either way I can imagine this could have impacts.

Note that at least Wix (as potential API consumers) are avoiding it entirely, so UMA won't tell us much about such cases.

Scanning through HTTPArchive data, I see that at least a few cases would benefit from it, but I need to improve my query to be more effective...

On Tue, May 26, 2020 at 11:49 PM Hiroki Nakagawa <nhi...@google.com> wrote:

Hi Yoav,

I agree this seems to have high-impact on applications that heavily use importScripts(), and it's nice to fix it.

As I replied in the crbug, this probably needs some architectural changes in worker/loader implementation that take time. The worker thread should be blocked until all scripts are fetched, but I'm not clearly sure how to implement it yet (fetching scripts in background threads and waiting for completion of them using base::WaitableEvent?). I roughly estimate this work will take 1+ quarter for investigation, designing, implementation, and testing on all worker types.

I'd love to better understand the complexity this entails. I imagined we could kick off async fetches (that go on to be fetched by the network service) and then wait the worker thread on their responses, but admittedly, I'm not familiar with the details here.

[Kenji Baheux]

Wix is a reasonably large player.

Yoav, do you know for what aspect(s) of their product they are currently using workers?

I'm guessing that their need aren't too specific and so depending on what they are using it for, it's likely that other CMS (possibly more categories) would be interested in replicating their approach (provided that we fix the performance issue).

In terms of assessing the potential impact, we can ask them to run a lab A/B between Chrome and Firefox, as that would at least give us an order of magnitude.

Also +1 on Yoav's question about understanding the complexity this entails. Perhaps, there are alternatives to uncover?

--

Kenji BAHEUX

Product Manager - Chrome

Google Japan

[PhistucK]

Is it worth it to even bother to optimize this detail while module workers are already a thing (I am guessing import statements are better optimized?) and probably the future?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "loading-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loading-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/loading-dev/CADWWn7WkiG%3D93FL_BEukPKQbpwOxdERrFNr39YDLjhwLrzuqWQ%40mail.gmail.com.

[Yoav Weiss]

On Wed, May 27, 2020 at 11:14 AM Kenji Baheux <kenji...@google.com> wrote:

Wix is a reasonably large player.

Yoav, do you know for what aspect(s) of their product they are currently using workers?

I'm guessing that their need aren't too specific and so depending on what they are using it for, it's likely that other CMS (possibly more categories) would be interested in replicating their approach (provided that we fix the performance issue).

Dan from Wix (on this thread, hi Dan! 👋) can correct me if I'm misrepresenting him, but my understanding is that they use workers in order to run the business logic of their different "site types" (e.g. blog, restaurant, storefront, etc). IIUC, a single site can load multiple types of that logic, resulting in many imported scripts.

 

In terms of assessing the potential impact, we can ask them to run a lab A/B between Chrome and Firefox, as that would at least give us an order of magnitude.

As they don't currently use importScripts, I'm not sure such testing would be trivial. (other than creating synthetic test cases, which we could as well)

[Yoav Weiss]

On Wed, May 27, 2020 at 11:51 AM PhistucK <phis...@gmail.com> wrote:

Is it worth it to even bother to optimize this detail while module workers are already a thing (I am guessing import statements are better optimized?) and probably the future?

If there is content out there that would benefit from this change, we should make importScripts faster.

If there isn't, then maybe the right path would be to tell developers to use module workers and `import` instead. Given that other vendors don't support module workers just yet, and AFAICT module workers are not yet supported in Service Workers anywhere, I don't know if that's a reasonable path.

[Yoav Weiss]

FWIW, ran an HA query to gather some results on this and found ~30K worker scripts that would benefit from this change.

(BQ query, results)