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

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)

When its going through the tests it seems fine from there on out (EDIT: Actually it is slower when running tests as well. It goes through one by one at the speed of 0.5 secs while the norm feels like 0.05
secs per test)
However it is slow on starting up and/or initiating jest tests (about 4-6 seconds delay, 4-6x slower than mac machines)

I will try watchman and get back to you

If you could profile using e.g. ndb the startup and figure out what's slow, that'd be a big help as well 🙂

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

@pfftdammitchris what is your [exact] usecase where you noticed the slow?
(one file or multiple files)? (watch mode or no)? can you provide the exemple.
for one file watch mode problem => please read my last comment in: #6783

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.

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 https://github.com/facebook/jest/issues/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.

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.

We have a suite of 144 tests files with 1302 tests that take 1 minute and 43 seconds to run on a Windows 10 build 15063 machine, Core i7 with 16GB , and they takes 28 seconds on a MAC OS Mojave with 32GB. Our development team is split evenly between Windows and Mac and the numbers are very repeatable.

Here's a simple test -

it("works", () => {
  expect(1).toEqual(1);
});

I put it in codesandbox and it runs pretty much instantly - https://codesandbox.io/s/4q8l0q52lw

on my Windows machine though it takes 4-5 seconds -

PASS src/index.test.js
v works (62ms)

Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 4.158s
Ran all test suites.

The test itself took 62ms, but the rest of the test harness took 4 seconds. Re-running the test by hitting Enter it takes the same amount of time.

My settings -

> npx envinfo --preset jest

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.12.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.10.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.4.1 - C:\Program Files\nodejs\npm.CMD

I tried it with the WSL Ubuntu and got the same results (4-5 secs) - those settings -

  System:
    OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  Binaries:
    Node: 8.10.0 - /usr/bin/node
    npm: 3.5.2 - /usr/bin/npm

I'm just getting started with Jest so have pretty simple tests, and they can take 15-20 seconds to run. I'd love to have them running quickly - I tend to lose my train of thought otherwise!

@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

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.

@nasreddineskandrani i am trying out [email protected] but i can still see extremely slow execution when running with watch mode any help would be much appreciated.

@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

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.

@TomMahle this is a super bad newz :( (the regression we are talking about on top was in 23.6 already)
Right now a simple 'sample' project did show good perf. after micromatch update.
so we need real problematic project to debug, you project is private? or public?

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 p 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 Enter to re-run the test rather than having jest do it automatically, but I guess that's not relevant to the issue at hand.

@nasreddineskandrani. Unfortunately my project is private. If there's any smaller code samples (the jest config?) Or statistics I could provide I'm happy to do that, though. All the tests seem to be dramatically slower (only on windows) so I don't think it has to do with the specific tests.

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

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.

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(tm)-8320 Eight-Core Processor 3.50GHz
16GB ram
x64
SSD

Let me share my profiling here.
Specs:

• Windows 10 Pro
• Node 10.15.3
• Intel Core i7-4702MQ 2.2GHz
• 8GB RAM
• x64
• SSD

Steps:

1. npx create-react-app my-app --typescript
2. change App.test.tsx
3. run npm test

CPU Profile:

CPU-20190801T141211.zip

Is it expected that 15 seconds are spent only with requring modules for single trivial React component and test?

Can someone with more experience on CPU profiling take a look?

112 tests
windows 10
first run 507 seconds
second run 23 seconds
linux sub system
frist run 54 seconds
second run 29 seconds

85 tests
windows 10
first run 44 seconds
second run 15 seconds
linux sub system
first run 26 seconds
second run 15 seconds

Kepro these results are with micromatch 4?

I prefer direct chat than having 1 millions message here it's really becoming a hell to follow cross all issues that are related to the same topic.
You can join here. https://gitter.im/wearefrontend/jest-slow-windows
I am on it now...

Gitter is blocked over my company VPN - if you lovely people could post any meaningful updates here that would be amazing <3

you can still connect at home to do some open source :P 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

@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 :D

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!

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

--runInBand for me just make it even slower. 1200tests. Without runinBand 70/50seconds. With --runInBand its 90 second on second runs at best
On linux its like 5-8x faster

Try --maxWorkers=4 then.

@cino893, not a solution :) try to find fix not a workaround

Any news on that? I stacked on version 21 because of that bug. v22 is slow and v23 is even slower.
Don't you guys think it is high priority bug?

Where I work, we do not have freedom to choosing OS nor to install Ubuntu on Window or something similar.

@gombek have you tried v25? The Jest team have made a lot of performance improvements across the board.

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.

@gombek have you tried v25? The Jest team have made a lot of performance improvements across the board.

I'm using Jest v25 on windows and it is still slow

@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 only have around 20 tests and I've just taken some timings with jest --watch, both on the intial run and then pressing enter to re-run them.

On Windows it took about 15 seconds both times whereas for linux it was around 5.3 seconds for the first run and 2.3 on subsequent runs.

I tried using -t="GARBAGE" to cause all the tests to be skipped. the linux one took 1.5 seconds but windows still took 13, so it seems to me that it's not the actual running of the tests that's taking the time!

Both machines are using the latest version of node and jest, and the linux is actually a VM running inside the Windows one using hyper-v, so other things being equal I would expect the Windows one to be faster.

I only have around 20 tests and I've just taken some timings with jest --watch, both on the intial run and then pressing enter to re-run them.

On Windows it took about 15 seconds both times whereas for linux it was around 5.3 seconds for the first run and 2.3 on subsequent runs.

I tried using -t="GARBAGE" to cause all the tests to be skipped. the linux one took 1.5 seconds but windows still took 13, so it seems to me that it's not the actual running of the tests that's taking the time!

Both machines are using the latest version of node and jest, and the linux is actually a VM running inside the Windows one using hyper-v, so other things being equal I would expect the Windows one to be faster.

Yes. And if you mount the source codes to the linux VM from Windows and run the tests they get as slow as they are in Windows. This strongly implies that the problem is in Jest's file handling logic like I mentioned earlier.

Yes. And if you mount the source codes to the linux VM from Windows and run the tests they get as slow as they are in Windows. This strongly implies that the problem is in Jest's file handling logic like I mentioned earlier.

I noticed that while the tests are running the CPU is high but disk usage is not. It it was to do with blocking on file handles, I would expect it to be low CPU (unless jest is somehow in a tight loop waiting for handles to be released)

I saw hevans90's comments on file watchers. I don't have any third-party anti-virus installed or similar installed, but disabling the Windows built-in real-time protection made no noticeable difference.

hope this if of some help to anyone who has the time to try and debug it.

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

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

hmm I just tried that and it didn't seem to make any difference to mine (mind you, mine wasn't taking minutes, so maybe we are experiencing different problems)

I always have exclusions in place anyway. And actually IntelliJ Idea automatically suggest placing workspace directory into exclusions and does that for you if you let it (you should). So in my case slowness is not due to Windows Defender or any other virus scanner.

Performance difference is 5-10x compared to a Mac. PC is a powerful desktop machine (read: much faster than the macbook). Everything else is lightning fast, just Jest is suffering from this issue.

any updates on this? ... i am experiencing the same thing, each test takes a long time to setup and loads but after the first one is loaded, it runs at a normal speed.....

Also having this issue. A single test file with a single, hello world test and it takes ~15 seconds to start up, plus another 12 seconds to run the test.

👋 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): https://github.com/kulshekhar/ts-jest/issues/908#issuecomment-484043250

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.

👋 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.

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

Also having this issue. A single test file with a single, hello world test and it takes ~15 seconds to start up, plus another 12 seconds to run the test.

Just ran the same test on a Mac. It takes about 1.5secs to start, <1sec to run the test.

Also using JS, not TS here.

Pure JavaScript with Jest as well here. I have a powerful quad core laptop with intel's 10gen processors and everything else is blazing fast, but [email protected] is taking 2-3 times more on Windows vs Linux to run some basic tests.

Same issue, about 60 seconds for my tests to run on windows, and no UI is displayed for the first 45 seconds or so. Ran the same exact test suite on my linux machine and it took 8 seconds to run to completion.

@Cellule's comment above sped things up dramatically to around 15 seconds.

@ryanrapini followed @Cellule 's advice (but went through the Windows UI > Virus and Threat Protection > Manage Settings > Add Exclusions) and saw that some tests went from 13 seconds to 6, so basically half. Thanks!

Anyone wanna contribute a section mentioning Windows Defender (or AV in general?) on the FAQ page of the website? https://jestjs.io/docs/en/troubleshooting

I can confirm that using isolatedModules: true with ts-jest made a HUGE difference on cold startup (~10mins => 15sec)
I haven't tested their improvement in the alpha because I'm waiting on #9457 to be addressed before updating to jest 25

Hi all,

Same problem here and no solution works for me...

I run some very simple code on which I have currently a few tests.
It's from the "Advanced React Course" of Wes Bo.
He runs it on Mac, and gets an immediate answer from his computer.

And for me:

Test Suites: 2 skipped, 15 passed, 15 of 17 total
Tests: 6 skipped, 37 passed, 43 total
Snapshots: 18 passed, 18 total
Time: 5.869s
Ran all test suites.

isolatedModules: true changes nothing in my case, I am still around 5-6 seconds.
And when I start testing with any option, it takes 9~10 seconds.

Adding my dev folder on the Defender Exceptions did nothing either:

Test Suites: 2 skipped, 15 passed, 15 of 17 total
Tests: 6 skipped, 37 passed, 43 total
Snapshots: 18 passed, 18 total
Time: 5.563s
Ran all test suites.

Is there any good option on Windows ?
Do I need to go for wsl2 ?

Hi all,

Same problem here and no solution works for me...

I run some very simple code on which I have currently a few tests.
It's from the "Advanced React Course" of Wes Bo.
He runs it on Mac, and gets an immediate answer from his computer.

And for me:

Test Suites: 2 skipped, 15 passed, 15 of 17 total
Tests: 6 skipped, 37 passed, 43 total
Snapshots: 18 passed, 18 total
Time: 5.869s
Ran all test suites.

isolatedModules: true changes nothing in my case, I am still around 5-6 seconds.
And when I start testing with any option, it takes 9~10 seconds.

Adding my dev folder on the Defender Exceptions did nothing either:

Test Suites: 2 skipped, 15 passed, 15 of 17 total
Tests: 6 skipped, 37 passed, 43 total
Snapshots: 18 passed, 18 total
Time: 5.563s
Ran all test suites.

Is there any good option on Windows ?
Do I need to go for wsl2 ?

Can you try to apply my solution and tell me if it does anything? (actually Cellule's solution, but I did it via the menu instead of running a script)

Can you try to apply my solution and tell me if it does anything? (actually Cellule's solution, but I did it via the menu instead of running a script)

As I said in my message, I already did that :)

I mean I followed what you did, via the menu and all.

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

Same issue on Windows here with vanilla javascript as well as a fresh typescript project. 2 seconds to run 9 unit tests which run in <10ms using mocha.

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 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 just tried the same thing as @JPustkuchen & the performance goes from ~10s to < 1 second.

I excluded my project folder from Windows Defender but Jest is still running slow.

I don't know if this is still being worked on, but I notice that when I do a typo in the code, the tests in watch mode instantly fail. Which leads me to the thought that it's not actually forcing a new directory crawl before compiling the test. Very simple tests are taking 10 seconds for me as well.

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.

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.

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 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.

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.

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 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).

@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 :P

Pressing enter makes the test run in around 200ms.

@nasreddineskandrani Did you try it vice versa? I mean, copying the tests from the slow repo to yours? But I don't think the issue is with the repo that I posted. As we can clearly see, many people are having the same issue, I was just posting a reproducible example.

@kentcdodds Will you be our hero one more time?

@SimeonRolev In my benchmark i dont see the same issue as in Kent repo. You have something in Kent Repo. that cause this slow => outside of it jest is faster.

This github issue is related to Jest performance windows vs macOS/Linux since they didnt' reach same perf. they didnt clause it i guess. (its far better now than 2 years ago with jest v23)

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: