Menu
While not always true for everyone, there seems to be a majority (anecdotal from others I've spoken with) that experience faster Jest runs with --maxWorkers=50% (or some similar setting) than without it set or setting it to 100%.
Example blog on the subject
My personal experience with an 8 core machine is that if I don't set --maxWorkers then I will have 7 concurrent workers running (as expected coreCount - 1) and it will run slower than if I set --maxWorkers=50% which creates 4 concurrent workers.
Why this is happening doesn't make sense to me. i.e. allocating more resources slows this down instead of speeding it up. Can anyone explain this?
838
As you may read in the documentation --maxWorkers in single run mode (not watch mode) by default is set to the cores available on your machine, or your CI runner minus one for the main thread.
It may be useful to adjust this in resource-limited environments like CIs but the defaults should be adequate for most use cases.
For environments with variable CPUs available, you can use percentage-based configuration: --maxWorkers=50%
In this article in Adobe Tech blog you would see a benchmarking and their explanation of why setting --maxWorkers=50% saved them some time.
In short, they explained how Jest is greedy in terms of resources, it uses all your CPU cores to run tests in parallel, which may cause peaks in memory usage and timeouts as it has to maintain a worker pool of child processes that run tests at a cost.
This article presents a benchmark that shows that may make us assume that this issue might be caused by Node.js
And that's why this might be reduced if you use half of your machine's cores, or even better sometimes by using --runInBand (or --maxWorkers=1) which is recommended in Jest's troubleshooting guide:
While Jest is most of the time extremely fast on modern multi-core computers with fast SSDs, it may be slow on certain setups as our users have discovered.
Based on the findings, one way to mitigate this issue and improve the speed by up to 50% is to run tests sequentially.
So my answer would be:
That cost of spawning and scheduling multiple jest-workers might be sometimes greater than the gains we may get with parallelization. By using multiple workers you are instantiating more objects that will load different files from the disk. That's why in small and atomic tests you don't see any (or just a small) performance gain by using --maxWorkers=50%|1.
Read more:
86
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
