Open janpio opened 5 years ago
@janpio Can we get an update with Cordova CLI 9 on the same computer.
Running cordova -v | gnomon
five times on my macOS computer, has an average of 0.47674s
No improvement:
E:\Projects
λ cordova -v | gnomon
1.5790s 9.0.0
0.0019s
Total 1.5849s
E:\Projects
λ cordova -v | gnomon
1.6072s 9.0.0
0.0019s
Total 1.6105s
E:\Projects
λ cordova -v | gnomon
1.5453s 9.0.0
0.0026s
Total 1.5522s
E:\Projects
λ cordova -v | gnomon
1.5194s 9.0.0
0.0019s
Total 1.5253s
E:\Projects
λ node -v | gnomon
0.0117s v10.15.1
0.0016s
Total 0.0159s
(Windows 10)
It seems like telemetry negatively affects this:
$ cordova -v | gnomon
1.3160s 9.0.0
0.0005s
Total 1.3167s
$ CI=1 cordova -v | gnomon
0.4831s 9.0.0
0.0005s
Total 0.4842s
My timings were with telemetry already disabled, with it on it adds ~0.2 to ~0.5 seconds.
The relevant bit for me here was how cordova -v
is slower than other Node based CLIs like npm
or ngrok
.
I did some profiling and about half of the time is spent by require('insight')
. When you drill down a bit, you can see that the actual culprit that causes the long loading time is Rx.js
which is required by inquirer
, a dependency of insight
.
Roughly the other half is spent on loading cordova-lib
. There's a few things I wanted to do about that for some time, but I haven't gotten to it. The Problem with improving the loading time there is that a lot of modules require way more than they would have to. I have some WIP to improve that, but it's quite some work since test doubles are affected when changing requires etc.
My times for cordova -v
are as follows:
cordova@latest
: 1050 msinsight
: 700msinsight
and cordova-lib
: 190msbin/cordova
: 100msFollow-up: inquirer
already fixed the problem by only importing what they use from rxjs
. But insight
does still use an older version of inquirer
.
Edit: tested with the latest version of inquirer
but it only improves the loading time by around 100ms. They are working on a major refactor that should improve it even more though.
For cordova-lib
cordova.serve
was the biggest offender regarding module load time. However, this is to be taken with a grain of salt because of Node's module caching. Meaning if you don't load cordova.serve
, other modules that share the same dependencies could take longer to load, since their dependencies haven't been cached by loading cordova.serve
.
Well the question in the title is answered. Should we close this or rename it to something more actionable?
Renamed to a task that benefits of both the measurements and your analysis.
See also the discussion from a while back at https://github.com/apache/cordova-discuss/pull/70 (and subsequent PR to remove lazy-loading from cordova-lib: https://github.com/apache/cordova-lib/pull/562)
Thanks for the links @dpogue! I think the reason while lazy loading did not bring any real benefits as it was being dropped is that you basically load almost everything of lib, once you load something. That can be improved. I have some work in progress regarding that lying around. Don't know when I'll get to continue it though.
Telemetry code has been removed, so hopefully that improves the startup speed a bit
Even with telemetry turned off, our CLI seems a bit slow sometimes:
(Yes, I am working on a not very powerful machine here) (
ionic
is even slower with >7 seconds - but that's no excuse ;) )