Skip to content
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

Times don't add up to total time #83

Closed
jtheisen opened this issue Jun 11, 2019 · 4 comments
Closed

Times don't add up to total time #83

jtheisen opened this issue Jun 11, 2019 · 4 comments

Comments

@jtheisen
Copy link

Is it expected that the individual timings don't add up to the general output time?

This is what I get on one project:

 SMP  ⏱
General output time took 17.75 secs

 SMP  ⏱  Plugins
SourceMapDevToolPlugin took 0.341 secs
DllReferencePlugin took 0.029 secs
MiniCssExtractPlugin took 0.012 secs

 SMP  ⏱  Loaders
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\ts-loader\index.js took 13.32 secs
  module count = 34
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\mini-css-extract-plugin\dist\loader.js, and
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\css-loader\dist\cjs.js, and
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\sass-loader\lib\loader.js took 8.99 secs
  module count = 1
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\css-loader\dist\cjs.js, and
C:\Users\jens\Documents\Projects\VisBricks\VisBricks.Crm\ClientApp\node_modules\sass-loader\lib\loader.js took 4.99 secs
  module count = 1
modules with no loaders took 2.4 secs
  module count = 152

I saw the tickets about multiple entries with the same loaders, but a) I don't know why it happens here, I don't have more than one rule for css and b) the times still don't add up to the general output time when I ignore one of them.

How am I to interpret this result?

@stephencookdev
Copy link
Owner

Yes, the general output time is everything that webpack does, it's the full time it takes for your build to happen.

As well as running loaders and plugins, webpack also does things entirely by itself (such as writing your output files to disk, for example) which can't really be attributed to any particular loader or plugin.

I want to try and make things clearer in the output itself - but hopefully that clears it up for you?

@jtheisen
Copy link
Author

The ts-loader takes over 13s, the next loader chain over 8s,and the sum 21s is already more than the general output time in this case. That's what I find weird.

@avin-kavish
Copy link

@stephencookdev I have the same problem. Do you have any suggestions as to how I can find out exactly what is consuming the extra time? My general output time is at 12 seconds for each incremental build while babel-loader takes only 0.3s when I change a single line of code with HMR enabled.

@stephencookdev
Copy link
Owner

This plugin looks at how long each entry and exit to a loader takes. Anything happening outside of that is webpack's internals.

This could be stuff like accessing the filesystem (e.g. reading/writing files), handling the dev server, or any other job that webpack does that's not specifically a loader or a plugin (webpack does quite a lot of stuff).

You can try using webpack 4's profiling plugin if you want to get down and dirty to really work out what's taking time. But I would probably recommend just following some general speed up tips, like you can read about here or here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants