Open stereokai opened 6 years ago
@stereokai thanks for opening this issue!
I love the numbers you collected. Could you run your example project with hard-source-webpack-plugin@alpha
? The 0.6
series is improving a lot of internal mechanisms for sanity and performance. I'm seeing projects both have faster initial build times and build after quitting dev server times.
In concept HardSource and DllPlugins should improve build times together. A big differentiator would be source-maps. The Dll being built separate doesn't need source-maps to be rebuilt like chunks containing your modules that change. Even with source-maps disabled, Dlls should provide a build time benefit from not having to track all the internal dependencies it, and building the source of the Dll's chunk.
In practice there could be an interaction between HardSource and a DllReferencePlugin that could slow them down when working together. By extension it could be HardSource and AutoDllPlugin together or AutoDllPlugin alone slowing down the build. HardSource like webpack itself has evolved a lot of its performance saving techniques over time, getting better with each iteration.
On discussing build caching and webpack there is this gem: https://twitter.com/TheLarkInn/status/949578212467654656
I'll try alpha 0.6 and update here! Cheers :)
I started timing even more extensive metrics than last time. I'll update soon ;)
@mzgoddard @TheLarkInn @timse @asfktz
I have an update for ya'all!
I'll start with the takeaways and if you want all the fine details, you will find them below.
webpack-dev-server
, the gains introduced by HardSource are just mind blowing. AutoDllPlugin on the other hand, not only does not speed things up but it actually slows WSD
down.Let's get straight down to business. All measurements are in seconds and shorter is better:
webpack-dev-server
In the above chart it is obvious and incredible how HardSource just blows DllPlugin out of the water by reducing the **cold rebuild*** time comparatively to the time it takes WDS
to do one HMR. AutoDLL fails to optimize anything, and combining it with HardSource only takes away from the its staggering optimization.
* cold rebuild means running WDS
for the second time, after running it once and quitting it entirely.
Comparing first HMR to subsequent HMRs: I noticed a telling pattern where the time to HMR decreases exponentially up to a certain point. In other words, the first HMR after WDS
finishes initialization would take the longest, and any subsequent HMR sequence takes less and less time until, I guess, a technical limit. The difference between the two is small (4 seconds at the most), but it was repeatable and therefore is another metric to go by when comparing the performance of the plugins.
Takeaway: HardSource's superiority is again evident and based on all of my WDS
measurements, it can be said DllPlugin brings no value with WDS
.
webpack
Comparing dev to production: I decided this time to take a more extensive approach and measure not only webpack-dev-server
but also our production configuration.
Takeaway: There's something very interesting happening here: AutoDLLPlugin cut our initial build time, that is, before it was able to cache anything, by 10% (8 seconds). That took me by surprise! Using HardSource, reduces the build time with its cache, but results in a longer initial build time.
Now we'll look at the most significant metric. In the last chart featured right above, I am comparing between the initial production build time and rebuild with each plugin by itself and finally with both of their superpowers combined. As the numbers tell, for non-dev-server webpack, the combination of HardSource and AutoDllPlugin shortened the build from 75 seconds to 25 seconds. That's 3 times shorter!
Similar question, does it make sense to use cache-loader and hard-source-webpack ? I seem to get similar results with either one:
Default build time: ~1min15sec
CacheLoader
SMP ⏱
General output time took 30.31 secs
SMP ⏱ Plugins
BrotliPlugin took 9.7 secs
OptimizeCssAssetsWebpackPlugin took 9.48 secs
TerserPlugin took 0.652 secs
VueLoaderPlugin took 0.303 secs
WebpackWatchedGlobEntries took 0.132 secs
AssetsWebpackPlugin took 0.041 secs
MiniCssExtractPlugin took 0.016 secs
ContextReplacementPlugin took 0.009 secs
ProvidePlugin took 0.006 secs
HardSource (default settings):
SMP ⏱
General output time took 35.39 secs
SMP ⏱ Plugins
TerserPlugin took 12.94 secs
OptimizeCssAssetsWebpackPlugin took 10.026 secs
BrotliPlugin took 9.77 secs
HardSourceWebpackPlugin took 1.29 secs
WebpackWatchedGlobEntries took 0.127 secs
AssetsWebpackPlugin took 0.109 secs
MiniCssExtractPlugin took 0.023 secs
ContextReplacementPlugin took 0 secs
ProvidePlugin took 0 secs
VueLoaderPlugin took 0 secs
Measure with SpeedMeasurePlugin
I have been looking into ways to optimize our build speed, and arrived at the caching options offered by DllPlugin/DllReferencePlugin and HardSourceWebpackPlugin.
Installed and examined both HardSourceWebpackPlugin and DllPlugin/DllReferencePlugin. (Side note: I used AutoDllPlugin, which provides similar behavior to HardSource in terms of detecting when DllPlugin should recompile its cache).
Both plugins seem to do great work. I measured the following with webpack-dev-server:
Vanilla
Original build time: ~48 seconds Rebuild after quitting the dev server: ~44 seconds Subsequent HMR after small JS change: ~7 seconds Subsequent HMR after small CSS change: ~1 second
DllPlugin/DllReferencePlugin (using AutoDLLPlugin)
AutoDLLPlugin initial build time: ~50 seconds Rebuild after quitting the dev server: ~42 seconds Subsequent HMR after small JS change: ~6 seconds Subsequent HMR after small CSS change: 2-3 seconds
HardSource
HardSource initial build time: ~58 seconds Rebuild after quitting the dev server: ~2.5 seconds Subsequent HMR after small JS change: ~3 seconds Subsequent HMR after small CSS change: ~1 second
HardSource and AutoDLLPlugin
Initial build time: ~62 seconds Rebuild after quitting the dev server: ~3.6 seconds Subsequent HMR after small JS change: ~3 seconds Subsequent HMR after small CSS change: 2-3 seconds
I took these measurements because I am under the impression people are using both plugins in tandem (please see the references at the bottom). However, through my experiment I can draw a few conclusions:
@mzgoddard @sokra @timse @asfktz I made this experiment in the hope of sparking a discussion and hopefully a process towards a community standard for tackling performance and build caching with Webpack.
References: