-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does it make sense to use both DllReferencePlugin and HardSourceWebpackPlugin? #251
Comments
@stereokai thanks for opening this issue! I love the numbers you collected. Could you run your example project with 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.
Let's get straight down to business. All measurements are in seconds and shorter is better: Dev builds with
|
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
HardSource (default settings):
|
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:
The text was updated successfully, but these errors were encountered: