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

Significant regression in dev watch mode performance #7546

Closed
MLoughry opened this issue Jun 16, 2018 · 5 comments
Closed

Significant regression in dev watch mode performance #7546

MLoughry opened this issue Jun 16, 2018 · 5 comments
Labels

Comments

@MLoughry
Copy link
Contributor

Bug report

What is the current behavior?
We recently upgraded from webpack 4.6.0 to 4.12.0, and found our watch mode build times balloon from 120s initial/17s rebuild to 250s initial/150s rebuild.

I used git bisect to determine that the regression was caused by #7373, which is a single-line change to clone chunkGroups arrays before processing them. Reverting this resolves the build time regression.

If the current behavior is a bug, please provide the steps to reproduce.
I don't have an easy repro, as our repository is quite large and can't be shared out. @TheLarkInn may be able to assist, since he would have access to our repository.

What is the expected behavior?
Not to regress dev watch build times

Other relevant information:
webpack version: 4.9.0
Node.js version: v8.11.1
Operating System: Windows 10
Additional tools:

@MLoughry
Copy link
Contributor Author

@sokra, there was no explanation included in #7373 or its linked bugs as to how the change was meant to fix the require.ensure() issue, and I'm not familiar enough with the code to understand. Obviously I can't simply revert that change, as it breaks your new tests and regressed those bugs; but I have no idea of another mechanism to fix it while fixing this perf regression.

@MLoughry
Copy link
Contributor Author

I did a bit more investigation, but I can't say it makes sense. The call to .slice() is, as expected, very quick. However, the call to this.processDependenciesBlocksForChunkGroups is significantly slower when given a cloned array, rather than the original.

I'll try to dig deeper later.

@MLoughry
Copy link
Contributor Author

I've temporarily worked around the issue in our build system by monkey-patching webpack to revert the offending commit, since the bug it fixed never affected us.

@webpack-bot
Copy link
Contributor

This issue had no activity for at least half a year.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@webpack-bot
Copy link
Contributor

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

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

No branches or pull requests

2 participants