Module scripts have very slow performance on certain module trees
Reported by
guybedf...@gmail.com,
Jul 11 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: I've extracted out a sample dependency tree of 170 modules from Babel code (with the code all removed, just leaving import relations), with some circular references, which practically brings the pipeline to a halt, taking almost 20 seconds to process. In Safari this same tree can load in under 200ms. 1. Clone https://github.com/guybedford/modules-slow-tree 2. Run a local server 3. Open /test.html What is the expected behavior? This module tree should be able to load a lot faster. What went wrong? It seems like an unnecessarily high order loop somewhere in the pipeline implementation or cache. Did this work before? N/A Chrome version: 61.0.3154.0 Channel: canary OS Version: OS X 10.12.5 Flash Version:
,
Jul 12 2017
It's definitely demonstrating the slowdown for me. I've attached a gif here of the page load process. I'm running on a 2014 Macbook Air, if there's anything specific about my environment that might be affecting this that you can think of let me know?
,
Jul 12 2017
Also note the Chrome version is 61.0.3155.0.
,
Jul 12 2017
Thank you for providing more feedback. Adding requester "rtoy@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 12 2017
Able to repro in Chrome 61 on linux.
,
Jul 16 2017
Note that in addition there is a bug here too in this test case that an error message "Binding not found" is supposed to be thrown but isn't.
,
Jul 16 2017
Actually, ignore my previous comment, I just ran the test case again and the missing binding error is no longer happening for me.
,
Jul 18 2017
,
Jul 18 2017
Adding Georg and Adam due to this being module related.
,
Jul 18 2017
,
Jul 19 2017
I suspect this is a dup of issue 722728 . At the least, https://codereview.chromium.org/2889783002/ should make this a lot faster by not queueing unnecessary tasks on the runloop.
,
Jul 19 2017
Not sure that exact patch will help: I tried adapting it locally and still see tens of thousands of tasks.
,
Jul 19 2017
Thanks Adam for looking into this. Could it be that there is unnecessary looping in the dependency algorithm, perhaps by calling a full top-level dependency trace on each individual module load instead of just the top-level module or something similar?
,
Jul 19 2017
Trace attached, showing huge number of tasks.
,
Jul 19 2017
I've instrumented the code to get some more concrete numbers. There are a total of 478,748 tasks dispatched by the ModuleMap. over 460,000 of them are dispatched here: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/ModuleMap.cpp?rcl=cd7e31fb911a98c7dc021d543e9dea8c553cdb1f&l=79 where we call ModuleMap::Entry::AddClient() for an entry that's already finished fetching. The rest of the notifications come from NotifyNewSingleModuleFinished, which loops over the clients. We dispatch to a total of 18,638, so over 100 clients per module, on average.
,
Jul 19 2017
Thanks. I'll try porting the patch which batches the Dispatch... tasks for a single MTL.
,
Jul 25 2017
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by rtoy@chromium.org
, Jul 11 2017Labels: Needs-Feedback