fix: limit number of workers when creating haste maps in projects #9259
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thymikee
commented
Dec 3, 2019
thymikee
changed the title
SimenB
reviewed
Dec 3, 2019
| @@ -5,9 +5,7 @@ | |||
| "**/node_modules": true, | |||
| "**/build": true | |||
| }, | |||
| "editor.formatOnSave": true, | |||
There was a problem hiding this comment.
Format on save may conflict with eslint fix, if editor settings for prettier differ
There was a problem hiding this comment.
seems silly to me to have editor specific config files checked in, but I'm not losing sleep over it 🤷♂
SimenB
reviewed
Dec 3, 2019
| @@ -122,7 +122,10 @@ const buildContextsAndHasteMaps = async ( | |||
| createDirectory(config.cacheDirectory); | |||
| const hasteMapInstance = Runtime.createHasteMap(config, { | |||
| console: new CustomConsole(outputStream, outputStream), | |||
| maxWorkers: globalConfig.maxWorkers, | |||
| maxWorkers: Math.max( | |||
There was a problem hiding this comment.
there's not meaningful test we can write, right?
SimenB
approved these changes
Dec 3, 2019
|
@scotthovestadt FYI whenever you get back. Not sure how this fits into your refactor |
This was referenced Jan 28, 2020
This was referenced Feb 4, 2020
This was referenced Feb 18, 2020
This was referenced Mar 3, 2020
This was referenced Mar 10, 2020
This was referenced Mar 24, 2020
This was referenced Apr 16, 2020
This was referenced Apr 30, 2020
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Partially addresses #9236.
When creating haste contexts and maps, Jest currently spawns
maxWorkersper "project". While it doesn't make a difference in a single-project workspace, it's a big deal for those using multiple projects.A quick-and-dirty-but-works solution is to limit the number of workers based on the projects number. It's sub-optimal, because we may have smaller and larger projects which we assign the same number of workers. However a proper solution would require more work. E.g. we could delegate
createHasteMapof each project to a worker pool created injest-core, instead of deferring parallelization tocreateHasteMapitself. Feel free to implement this solution. However, I'm not pursuing this, as @scotthovestadt has likely far more meaningful changes to haste map performance.In Jest own test suite, this diff result in haste map creation time drop from 3.1s to 0.8s on my machine, which is noticeable.