About the slow start of Midway
Midway will use ts-node to scan and require modules in real time when developing locally. If there are too many ts files (such as 200 +), it may lead to slower startup, especially in the case of non-SSD hard disks under Windows, resulting in frequent fullGC of Server for ts-node type checking, and each file load may reach 1-2s.
Generally, Mac is SSD, so there is basically no problem, but Windows will appear, and there will be no such problem after construction.
As shown in the following figure.
How to judge
- Clean up the ts-node cache first.
There is a directory of
ts-node-* in the temporary directory, which can be deleted (if you do not know the temporary directory, you can execute the
require('OS').tmpdir() output view on the command line).
Deleted the following similar directory.
- Start Midway with ts-node
Execute the following startup command.
// midway v1
cross-env DEBUG=midway* NODE_ENV=local midway-bin dev --ts
// midway v2
cross-env NODE_DEBUG=midway* NODE_ENV=local midway-bin dev --ts
The require duration of each file will appear, if the time is relatively long.
Solve the problem
Since a Server will be started inside
TS_NODE_TYPE_CHECK, when there are many special files, the type check will be done every require. If it causes serious startup impact, it is recommended to close it. The cost is that the type check is not performed at the start of the runtime. Because there is a prompt in the editor, the check is not performed at the runtime.
Add the following two environment variables before executing the command.
cross-env TS_NODE_TYPE_CHECK=false TS_NODE_TRANSPILE_ONLY=true NODE_DEBUG=midway* NODE_ENV=local midway-bin dev --ts
The following is the comparison effect of using the same items.
|First execution (no cache)||Second execution (with cache)|
|No optimization parameters||About 258s||about 5.6s|
|Add optimization parameters||About 15s||About 4.7s|
If you have any questions, please submit your warehouse + node_modules to us.