jest: Jest is 3x slower on all windows machines (Windows 10 and lower)

Hello, I’m experiencing same issue in here. I have a windows machine and WSL. I copied my project files to WSL to test this behavior. Here are the runs of same two basic tests: Windows 10(Version 2004): WSL 2(Ubuntu 20.04):

The tests are very simple:

The project is created with CRA, so there is no configuration to botch the settings, I added nothing in terms of Jest. The same tests run blazingly fast on mocha, almost instantly. I’m trying to set up a testing environment for our project, and I would really like to use Jest, but it seems as I add more and more tests, the test suite will be slower and slower it seems. Each tests seems to be adding 0.8 seconds, which is ridiculous, since they do nothing. Something is messing with test execution on windows, and I don’t know what. The problem was worse, a single test would take around 15 seconds, but when I added --runInBand and , the situation seemed to improve a little bit, but I think it is still not enough, considering mocha watch mode is instant.

Yarn is version 1.22.5, all other npm dependencies(like react and react-scripts) are latest.

I disabled the anti-virus and windows defender to see if it has any effect, but it doesn’t. Also, I disabled indexing for my project folder, to no avail neither.

Edit: I tried pressing enter, and the tests were as fast as on WSL:

Now I’m really confused 😃

But this seems still very slow, since it seems each test takes 0.3 seconds, which is a lot, considering they do nothing. I expect this suite to be completed under 0.1 seconds.

Edit 2: When I added 100 tests to my test suite, it took around 44 seconds to run them, even if I press the enter to run them:

Same test suites takes around 9-10 seconds on WSL:

I’m on a brand new MacBook Pro. As I have students on both MacOS and Windows 10, I decided to add two more partitions to my drive; one for Windows 10 and one for shared storage using Tuxera NTFS.

I ran into this speed issue today preparing a JavaScript lesson that incorporates unit tests. I’m actually running Jest from MacOS but the code and tests are located on the shared NTFS partition. Even with all suites marked as describe.skip, Jest takes more than 10 seconds to complete, both in single-run and watch modes.

8 suites 42 tests

I swapped jest for mocha and chai and runs came back down to about 1 second single and 10 milliseconds watch mode.

I swapped jest for mocha and chai and runs came back down to about 1 second single and 10 milliseconds watch mode.

Basically you didn’t read my last post. You wanted to promote mocha/chai … we all know about this… We are trying to make the regression of jest fixed. Either you help to do this [from my post] ...can you try with micromatch 4...or keep these useless comments out of the thread. Sorry to be direct but at some point there is no other way to say it.

On a more positive note, I’d just like to say I owe this bug a great debt of gratitude. It was the final straw that made me decide to switch to Linux for my main development workflow and I’ve never been happier. I can’t say I’d never go back because sometimes I have to work on legacy projects, but with ASP.NET core being cross-platform, the reasons for booting back into windows are becoming fewer all the time.

It is slow for both single and multiple files, with or without watch mode. Pretty much every time it runs any test there is a 3+ second delay on initializing the tests, and it is slow running the tests one by one by 0.3 or 0.4 or 0.5 seconds each while other test runners like mocha/chai would usually just run each as if it feels like 0.05 seconds each.

I use jest in codesandbox and they seem to run jest instantly on initialization/running tests, I watched my coworkers run jest on their mac machines and they run it instantly like normally. It’s just windows machines as far as I know. I use a windows machine at work and jest is having the slow problem there, and I also use a windows machine at home and the problem continues here.

I used --runInBand but it seemed to have slightly slowed down the unit tests even further by an additional 0.2 seconds each, based on feeling.

so, we all know that issue is stupid NTFS 😄

I have to disagree even if I know you tried to be funny. No other runners suffer from this issue. So even if the issue would come from NTFS behavior it’s still a Jest bug.

That being said, it might be due to difference in file handles. If Jest holds on to file handles too long it would slow down execution a lot.

Please @timrobinson33 let’s stay on topic. There is no reason jest should be 68 times slower than any other environment on Windows, considering Node works just fine on any platform. Also might I add, I have not experienced this problem with any other test runner.

I would wish so much that someone would at least acknowledge this is a problem. As it is now, my windows desktop machine which has plenty of power (read: much more than my co-workers macbook) is approximately 69 times slower than the macbook when executing tests! This is practically forcing me not to touch the frontend code since it is so inefficient for me to work on those due to Jest tests running so slow. We might have to move away from Jest if this doesn’t get fixed. Everything else is lightning fast but Jest tests are superduper slow. The time is spent on something else than actually executing the tests, when the actual test logic is executed those go really fast.

has anyone tried to migrate to vitest and had much faster tests on windows then?

EDIT: Well I have just tried it and it’s super fast! And it even has nice vscode plugin. I was struggling with jest for 2 days. But vitest looks like a good solution for my troubles. Migration was easy, as it’s reusing the jest API. I only had to create a ridiculously small config file and run it.

Since 2019 still we don’t have fix for this 😦

so, we all know that issue is stupid NTFS 😄

This is crazy!

Simply installed jest globally and now the exactly same project runs in 0.9s instead of 52(!!!) seconds! npm remove jest in the project, then npm install -g jest

Of course I’d like to integrate jest as dev dependency into the project again. Any idea why that happens?

@cino893, not a solution 😃 try to find fix not a workaround

Related: #6783

Is it slow starting up, or in watch mode as well? If just during startup, you can try to install watchman, that should help (https://facebook.github.io/watchman/docs/install.html)

Hi, just thought I’d add some additional information to this discussion. Jest is super slow also when executed inside a Docker container which has the source code and tests shared via volume from the host system (Windows).

I’m pretty certain this slowdown is due to the differences in how Windows handles file handles compared to unix systems. In unix, if a process has a file handle open that does not block other processes from reading that file. In Windows, a process holding a file handle owns that file as long as it releases the handle. I would look into Jest code for file reading logic and especially when and how file handles are released. A well behaving program should anyway release file handles immediately after it has done it’s job. Test runner like Jest should have no reason to hold file handle for a long time anyway.

Just mentioning that this will indeed improve test runner performance with WSL when cloning into home folder, but it’s not as fast as on native Linux (installed on bare metal, no VM or anything like that) and probably Mac. I ended up switching from Windows 10 to Linux in my client project.

If that’s allowed in your project, I highly recommend, besides Linux is much faster in most cases and every day usage compared to Windows.

Since 2019 still we don’t have fix for this 😦

So help fix it, this is an open source project. If you can’t contribute code, help adding more details about the root causes.

I also want to mention that @josh-barker’s solution also seems to work in my case. So here’s the present thinking: it seems that as long as Jest is installed under /home and not under /mnt, the performance is fixed.

So to summarize, the 2 main workarounds would basically be:

1. Install Jest globally with npm install -g jest and use that instead of a local installation under /mnt.
2. Move the entire project under /home, so that when you run npm install jest, it’ll be installed under /home as well.

Once again, for reference I’m using Windows 10 Home with WSL v2 and Ubuntu 20.04 LTS.

This is crazy!

Simply installed jest globally and now the exactly same project runs in 0.9s instead of 52(!!!) seconds! npm remove jest in the project, then npm install -g jest

Of course I’d like to integrate jest as dev dependency into the project again. Any idea why that happens?

This most definitely sounds like a virus scanner issue to me. Meaning, your project directory is in the scope of virus scanning which slows down jest to a crawl but your global npm directory is not. This is just a guess though.

I’ve moved to mocha/chai since then but i’m surprised this issue is still being worked on.

Clarification

I used --runInBand but it seemed to have slightly slowed down the unit tests even further by an additional 0.2 seconds each, based on feeling.

=> did you try with v24? from v23 to v24, You 'll see a good improvement for this scenario ONLY: on the rerun with watch and only if you run against one file (not on the first run) -> 2/3sec drop to 0.4/0.5sec . but compared to mac i never tried… so maybe it still bad… even with the current improvement

@SimenB

1. I consider #7110 as Jest speed regressions [v22 vs v23] on Windows for ALL problematic scenarios. where #6783 is one of them

2. I can consider this issue as: speed problem for jest [Mac vs Windows] for ALL problematic scenarios.

I tried with both versions at that time of the post.

I just created a new project with one test with simple array push tests and it took more than 10 seconds from start to completion. The project is using react/typescript but the test file is not a react component file but a normal file like a .js. Gif below for visual reference if it makes it better to visualize what the issue might be:

I noticed that the first time I run the test it shows that the test is estimated to be 9 seconds. Once it completes, it randomly retries the tests a second time to completion.

When I took that gif picture above (which was the second time this time), the time estimated cut down a little and it didn’t perform a second retry. Not sure if that is the expected jest behavior.

Here is a gif of me running micromatch 4 with yarn in a separate project:

Using windows 10 and my computer specs are: AMD FX™-8320 Eight-Core Processor 3.50GHz 16GB ram x64 SSD

@Southclaws issue is slow NTFS so Windows is the issue

@Glinkis can you try to hit enter after the first run is it still showin 1.6sec? (trigger a rerun)

---

@SimeonRolev i’ll take a look to the example you posted and see what kind of number i get with the same steps (pattern…) update: try1: i tried it i as u and got 6sec when i tried your steps -> drop to 3sec on rerun the same test (hit enter) try2: upgraded jest to 26.4 in Kent repo -> 3 sec first run near same for rerun try3: I took index.spec.js file from my benchmark test repo. and i dropped it to Kent repo. (deleting all other test files) -> surprise 2.8sec (SAME JEST 26.4.2, SAME COMPUTER, POWERSHELL, NODE_VERSION etc… as my test yesterday posted here)

I don’t understand this try3 still => ~3sec on rerun in Kent repo for my file but in my repo it drops to 0.300s on rerun (need someone to debug this) edit: Kent should be the one to check this 😛

Running the benchmark on my windows machine takes about 1.6s. I am not using WSL. I am using AVG antivirus, but have added exceptions for both the repository and node executable. My harddrive is an SSD.

Node version is v12.16.1

Updating the test instantly triggers the file watcher, but the actual time it takes to run that update is around 1s-2.4s.

I tested with v26.4.2 in my benchmark jest github repo. https://github.com/nasreddineskandrani/benchmark_jest node version in my computer: v12.13.0

pretty fine when i update the simple test (see screenshot)! For me jest is now correct for a simple test. If you have a problem at your job. You need to try to isolate the problem since by default it’s fine.

@empperi can you try my benchmark repo. example with the v26 folder and tell me how long it takes to run this test in your machine? if it’s not 0.166ms or around it you have an issue your side.

As expected, no difference to your test setup performance. Runs actually bit faster than on your computer. Changed your test setup to contain 100 test files under __tests__ and those too run fine. Since our app uses react-scripts I also added that to your example to check if that might cause the actual issue but no difference in performance.

HOWEVER then I tried to run those tests in WSL2 bash (against NTFS filesystem) and boom, execution time nearly 10x to raw powershell. Slower I/O speed is to be expected on WSL2 against NTFS but considering how simple this setup is (just 100 test files with single test on each one) it really shouldn’t affect that much. For reference, I executed this on WSL2 bash:

time find . -name "*.js" -print | xargs cat
...(file content prints omitted)...
real    0m0.138s
user    0m0.030s
sys     0m0.000s

Which shows it takes practically no time at all to read the file system from WSL2. For reference similar command in Powershell:

> Measure-Command { ls *.js | % { cat $_ } }

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 49
Ticks             : 499000
TotalDays         : 5,77546296296296E-07
TotalHours        : 1,38611111111111E-05
TotalMinutes      : 0,000831666666666667
TotalSeconds      : 0,0499
TotalMilliseconds : 49,9

Which shows the performance is on the same ballpark.

So, based on this I would say the issue might be caused how Jest uses I/O and that is somehow affecting the performance dramatically on WSL2. When it comes to the project that is causing me issues it is not a simple task to not require bash due to issues in code and tests (not done by me!). Considering the fact that WSL2 is gaining popularity I would say this is a real issue that should be looked into.

Hope this helps.

:edit:

Just out of curiosity I executed our test suite with --no-watch to see if watching the file system over WSL2 somehow affects things. The answer is no, it really doesn’t affect that much.

I’m also having this issue on Windows. The test itself runs in <1 second but the overall setup takes ~15 secondes to execute. I’ve tried it with v24 and v26, it’s actually a bit slower on v26

I did not have luck with any of the following (it did not improve the execution time) :

• adding --runInBand
• setting maxWorkers
• adding .ts .js .spec.ts .spec.js .tsx exclusions to Virus and Threat Protection, as suggested by @Cellule and @alessioalex

The delay is still slow even with watchman installed. I’ve run a profiling test with ndb running “jest --verbose”, here are the results:

Screenshot of the first 1.7 seconds:

Screenshot of 1.8 secs to 2.7 secs

A .json file and a .heapsnapshot file saved from the profile tab in ndb after recording:

profiling.zip

Does Windows 10 and lower in the title mean that it’s not an issue on Windows 11 or has it just not been tested?

I find this to be a breaking deal issue on my Windows 10 VM that runs on 4 Xeon 6148 cores, 40 tests take ~90 seconds there

But my Windows 11 12700k machine simply slashes through 5555 tests in 7 seconds. And I have the exact same results on both SATA SSD and HDD.

I get that there’s a huge CPU difference but it seems a bit too much to write off as just that.

I tested with v26.4.2 in my benchmark jest github repo. https://github.com/nasreddineskandrani/benchmark_jest node version in my computer: v12.13.0

pretty fine when i update the simple test (see screenshot)! For me jest is now correct for a simple test. If you have a problem at your job. You need to try to isolate the problem since by default it’s fine.

@empperi can you try my benchmark repo. example with the v26 folder and tell me how long it takes to run this test in your machine? if it’s not 0.166ms or around it you have an issue your side.

So I’ve confirmed today that Windows Defender makes a huge difference. I used to have a bunch of exclusion, but when I received my newer faster laptop, I couldn’t for the life of me figure out why jest took >10 minutes to run a single file.

Then I remembered exclusions. I can’t tell exactly which exclusions make a difference, but I got the runner to go down to <15sec instead of >10mins

I found a gist with relevant exclusions (albeit forceful) https://gist.github.com/darvell/edbc758b11ea4dcd7226b7c9f1821196 I also added file extensions .ts .js .spec.ts .spec.js .tsx

@pfftdammitchris I have compared pretty complex test suites on Mac + Windows and I see some differences, mainly from a cold cache Windows is notably slower, but once it’s hot I get similar performance between the two.

HOWEVER…

One thing to be extremely wary of on Windows in particular are intrusive kernel-level programs like Antiviruses/File-watchers like Carbon Black (or other real-time file watching software). If you have something like this running, you can see HUGE performance hits when running Jest. I am talking about it taking tens of minutes to run tests.

I worked for a company last year where the same test suite took ~30 seconds on a Macbook Pro & 20 minutes on a Windows laptop with these file-watching programs running.

I have no idea why, but I would hazard a guess it’s something to do with file-handles & how Jest uses some of the node.js filesystem APIs.

I thought enough attention had been given to micromatch’s maintainers so that this must’ve been ironed out already. Running(thus writing) jest tests on windows is a very unpleasant experience at the moment.

@pachumon the fix is not present in 24.8.0 as far as i understood

you need to set one dependency of jest to a specific version to remove the performance issue (theoretically) the fix will be by default present in jest 25 => read here to know how a dev find out this https://github.com/facebook/jest/issues/7963#issuecomment-483985345

to set the dependency (micromatch) to the version where the fix was done => you can check here i did an example in a little project https://github.com/nasreddineskandrani/benchmark_jest/blob/master/jest_24_with_micromatch4/package.json

Add to your package.json: (must use yarn not npm)

...
  "resolutions": {
    "micromatch": "^4.0.0"
  }
...

Hope this helps! and waiting for feedback

Microsoft Windows [10.0.22621.2428] node v18.16.0 jest 29.7.0

Temporary workaround for WSL2 Users: Install jest globally too (in addition to installing it as a dev dependency) and then use its binary’s absolute path in the package.json file instead of only jest, e.g.: "test": "/usr/bin/jest",. This will make it use the global jest binary instead of the one in the node_modules which for some reasons works 10 times faster.

Just chiming in to mention that @JPustkuchen’s workaround is also working for me i.e. installing Jest globally: npm install -g jest. Speedup was significant: went from ~36 seconds to ~3 seconds in wall clock time.

• For reference, I’m just testing the basic “1 + 2 = 3” test that’s shown in the Getting Started documentation.
• I’m using Windows 10 Home, WSL v2, and Ubuntu 20.04 LTS.

@josh-barker that should be because /mnt is NTFS until /home is ext

I realise this isn’t addressing the actual performance issue, but I’ve found a work around that suits me.

I’ve setup a devcontainer in VS Code - https://code.visualstudio.com/docs/languages/typescript and the performance is much better. I put my source in in my home directory - /home/<user>/<app>

It’s important that the code is not in /mnt/<drive letter>/some/path, as the performance is much slower there.

Pressing enter makes the test run in around 200ms.

I wanted to test if it’s the environment being the issue.

I was messing around with this repo: https://github.com/kentcdodds/react-testing-library-course/tree/tjs

• I go for npm test and all the tests start running in watch mode.
• I press ‘p’ to enter a pattern for a file and I type in “tdd-02”. I get 3+ seconds execution time.

I’d be surprised if Kent C. Dodds has a messed up environment in his paid course, but if he does, you can debug it there probably :? In his videos, it runs just fine, I think he uses a Mac.

I have to note something very strange that I can’t reproduce again - I had some consecutive test reruns that for one of the files (tdd-02…js) executed for about 0.1s, and for the file next to it (tdd-01…js)- about 3s. The code is almost the same and uses the same dependencies. So, I copied the code from the fast-running file and pasted it to the slow-running one and vice versa. The results were the same - the slow-running file remained slow and the fast-running file remained fast, with the actual codes swapped. This is getting crazy. Now both files run slow again (3-6s).

FYI: https://github.com/kulshekhar/ts-jest/pull/1549 will be in alpha version of ts-jest (possibly today). Anyone who is using ts-jest please help to test the alpha version and give us some feedbacks for https://github.com/kulshekhar/ts-jest/issues/1115

👋 I see a few replies hinting that they’re using typescript with jest - this might be worth looking into (if you’re also using ts-jest): kulshekhar/ts-jest#908 (comment)

The change for me was going from waiting 30 mins for jest (without a cache) to start to just a few seconds.

Bear in mind that setting the isolatedModules flag will result in no type-checking for your spec files (and the loss of some functionality): https://github.com/kulshekhar/ts-jest/blob/master/docs/user/config/isolatedModules.md

I’m only posting this here as it might be useful to determine if your issue is with jest.

Pure JavaScript here. I have this issue so not related to TypeScript.

Hi any news on this?

As a workaround you can use --runInBand if you start multiple tests. It will still took long to start the first test but the next tests will be fast.

My project took 21.803s for executing all tests. Now with --runInBand it takes only 7.412s

@nasreddineskandrani You got me. I’ve ordered a new macbook so will be out of open-source action until it arrives. I refuse to actually work on my crappy Windows box in my spare time 😄

It seems like the issue has moved in to the node/C++ realm, which is a little (extremely) outside my comfort zone - but I will do some digging!

you can still connect at home to do some open source 😛 and check it p.s. a dota game takes more time to queue now you can check gitter in this time 😉 this is where it is now: nodejs/node#28946

I am finishing a docker stuff i am doing for my personnal websites -> after (in a week) i’ll come back on this.

@TomMahle I’ll try my side to have a repo github with the problem you describe.

1. How many tests do you have?
2. are you enabling dom mode for the tests?
3. it’s react or angular? bonus:
4. can you try to reproduce the problem in a github repo to be able to debug? you can fork mine: https://github.com/nasreddineskandrani/benchmark_jest Or
5. maybe try my repo on your test machine? and see the results? between 23.6 and 24

Thanks for the suggestion about micromatch @nasreddineskandrani, but like @TomMahle above, pinning it to ^4.0.0 didn’t seem to improve performance for me either. 😢

I did find out one funky thing, though, which might help in diagnosing this problem.

I have the ability to run jest either on my native windows system, in a docker container with the main app directory mounted from my windows filesystem. Running in non-watch mode seems to have nearly identical behavior in both systems, which maybe suggests, as @thebearingedge implied, that the core problem has something to do with the NTFS filesystem, since my docker container is ultimately running everything except the filesystem in a linux VM.

However, on watch mode, things are slightly different: native windows always works slowly as expected, but the docker container only runs tests slowly on the first run. Once I tell it to run any test suite for the second time (e.g. by pressing <kbd>p</kbd> and entering a pattern), it runs the tests in well under one second (doing the same in native windows takes 3-4 seconds). The only downside of using docker is that the file change events don’t seem to propagate from my windows volume to docker, so I have to manually press <kbd>Enter</kbd> to re-run the test rather than having jest do it automatically, but I guess that’s not relevant to the issue at hand.

My test run time has also ballooned from ~2.5 minutes on 23.6.0 to ~15 minutes on 24.7.1 and 24.8.0. Our CI server is running windows and has seen a similarly large increase in build time with this upgrade. I’ve tried the micromatch dependency resolution override as mentioned above by @nasreddineskandrani to no avail. Please let me know if there’s anything I can do to assist with diagnosing this.

@bburns read above issue

---

@kensherman can you try with micromatch 4 in your yarn resolutions. to see if it’s better in windows please? https://github.com/facebook/jest/issues/7963#issuecomment-483985345

Hello all ! I cumulate the slowness of jest 24 and windows 10 (800s for 400 tests!). The faster way I found to speed up all of this is to use wsl instead of powershell or cmd. Now my tests takes “only” 189s.