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

Build times are significantly longer using SMP #82

Closed
daleyjem opened this issue May 22, 2019 · 9 comments
Closed

Build times are significantly longer using SMP #82

daleyjem opened this issue May 22, 2019 · 9 comments

Comments

@daleyjem
Copy link

I work on a project with multiple webpack configs (server & client) and the build times take a while... the reason I started looking into SMP to begin with.

Now with SMP, my build times have exactly doubled (6 mins --> 12 mins).

I like the idea of this tool for logging CI/CD build times, but it seems as though the intended purpose is occasional, manual use.

If I were curious enough to contribute to the project, where might I start trying to make optimizations so that the wrapper did not significantly increase total Webpack build times as much as they do?

@daleyjem
Copy link
Author

I wonder if getting the prettified loader names could be done after the the process and just concat them during.

/full/path/to/node_modules/some-loader/src/index.js?/full/path/to/node_modules/other-loader/dist/index.js

@daleyjem
Copy link
Author

Also, don't you want to tap into thisCompilation? I could be wrong on this, but compilation is going to fire multiple times within the plugin, whereas thisCompilation only once.

@stephencookdev
Copy link
Owner

Hey @daleyjem thanks for your issue.

SMP definitely isn't meant to double the compilation the time, and it's not something I've noticed in my projects. However, it does necessarily need to increase the compilation time, just because measuring takes time.

Some things could definitely be optimised! The prettifying of the loader names is a good example.

Please feel free to suggest some PRs, as long as the functional tests are passing, then the optimisations are probably all good

@jrnail23
Copy link

FWIW, I just measured my production builds on a somewhat smallish app, and builds that take an average of 11.1 seconds without SMP take 11.5 seconds with SMP, so it's only adding ~3.5% to my build time, which is totally acceptable in my book.

@daleyjem, perhaps there's something weird going on with one of your plugins (or something else in your webpack config) that's causing it to slow down significantly. Doubling your build time is definitely not a typical result.

@avin-kavish
Copy link

@daleyjem exactly how big is your project to require 6mins of build time? The last application I compiled that took that long to build was openCV with an output size of 4GB. I can't imagine a web project being that big.

@daleyjem
Copy link
Author

@avin-kavish I work for a very large company. We have 200+ of our own packages that require just about every Webpack loader under the sun (for CSS/image imports, etc.)

@avin-kavish
Copy link

Doesn't that solve the problem? Build each package separately, and use a private npm registry for sharing and versioning your internal packages.

@daleyjem
Copy link
Author

That's currently in the works... Pre transpilation. As of now though, every package is transpiled in a single build. I wanted to use SMP to show how time would be saved with pre transpilation.

@zdila
Copy link

zdila commented Jan 18, 2022

Build time of my project was 1m 25s. After adding SMP I had to Ctrl+C after 19 minutes.

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

5 participants