Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve performance of js-config-webpack-plugin #24
I'm submitting a...
Current & Expected behavior
Without the thread-loader, compilation takes three to four times less time on changes. We could remove it.
What is the motivation / use case for changing the behavior?
At least in the nitro example it works much faster without the thread-loader.
The "thread-loader" could be useful for a lot of files or with a different configuration (prewarming). Maybe even a configuration option makes sense?
I wrote a small node file to measure the behaviour.
The most important part are incremental build times.
The second test is running multiple full builds without dev server on the same machine:
The third test is running multiple full builds on a clean system (similar to a CI build):
Results for 1000 files instead of 100:
Just found out the reason for the performance delay:
So by default after 500ms all thread-loaders will be killed and have to be restarted for the next build.
Recompile times for 100 and 1000 components in seconds:
Thread loader with default poolTimeout
No thread loader
Thread loader with high poolTimeout
So it seems like no-thread loader is almost as fast as high poolTimeout (we would have to investigate that in detail)
Same result on travis:
Removing thread-loader improved the build speed by 65% for ts-loader and 65% for babel-loader:
This was referenced
Dec 18, 2018
I could fix the thread-loader
The results look promising (comparing version thread-loader 1.2.0 and thread-loader 2.1.0):
Time difference for 100 components:
1.171 s -> 378ms
average: '0.79s faster than the latest released npm version',
Time difference for 1000 components:
3.071s -> 1.34s
average: '1.72s faster than the latest released npm version',