Does it make sense to use both DllReferencePlugin and HardSourceWebpackPlugin?

[stereokai]

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:

1. HardSource exhibits marginally better results than DllPlugin, except for:
2. The area with the largest impact: consecutive full builds (ie. quitting the dev-server and starting it again). It is clear as day that HardSource really shines here and it is evident that the improvement here is on a whole other scale comparing to the rest of the measurements.
3. Overall and except for the previous point (which is arguably the most important one if we are considering CI/CD), in all other measurements the gains are nothing to write home about.
4. DllPlugin actually improved full rebuild time (not nearly as much as HardSource though), and very slightly improved JS HMR, but actually slowed down the time it takes to HMR CSS changes.
5. Combining HardSource and DllPlugin in this experiment did not prove to be beneficial. In fact, all of the gains made possible by HardSource (except JS HMR) were actually hurt by introducing DllPlugin (by way of AutoDllPlugin).

@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:

• 0–100 in two seconds — speed up webpack
• Keep webpack Fast: A Field Guide for Better Build Performance
• How we improved webpack build performance by 95%
• High-performance webpack config for front-end delivery

[mzgoddard]

@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

[stereokai]

I'll try alpha 0.6 and update here! Cheers :)

[stereokai]

I started timing even more extensive metrics than last time. I'll update soon ;)

[stereokai]

@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.

• Takeaway no. 1: With 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.
• Takeaway no. 2: On production builds, AutoDllPlugin reduces the initial build time (before DllPlugin caches anything!). HardSource shortens consecutive builds, but increases the initial build time.
• Takeaway no. 3: Using HardSource and AutoDllPlugin in tandem in our production build cut its time by 66% (ie. 3 times shorter!)

Let's get straight down to business. All measurements are in seconds and shorter is better:

Dev builds with 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.

Production builds with 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!

[Herz3h]

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