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

[pfftdammitchris]

🐛 Bug Report

Jest is slow on windows machines.

To Reproduce

Anyone with a windows desktop machine.

Expected behavior

It should be lightning fast.

Run npx envinfo --preset jest

Paste the results here:

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
  Binaries:
    npm: 6.2.0 - C:\Program Files\nodejs\npm.CMD

I've done a ton of reading around and it seems like 100% of all windows users are being affected by delaying in running tests with jest, while it is blazingly fast for all mac users.

Has there been any research or attempts to find what is causing this? Currently I'm copy and pasting all of my components and unit testing them in codesandbox, (It instantly runs tests blazingly fast) then copy and pasting them back into my project, which isn't the most ideal way to do it but I love the API that jest offers.

[SimenB]

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)

[pfftdammitchris]

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

[SimenB]

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

[pfftdammitchris]

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

[nasreddineskandrani]

@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

[pfftdammitchris]

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.

[nasreddineskandrani]

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.

[Darkein]

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.

[kensherman]

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.

[bburns]

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!

[nasreddineskandrani]

@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

[thebearingedge]

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.

[nasreddineskandrani]

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.

[pachumon]

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

[nasreddineskandrani]

@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

[TomMahle]

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.

[nasreddineskandrani]

@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?

[toolness]

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.

[TomMahle]

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

[nasreddineskandrani]

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

[kostadinnm]

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.

[pfftdammitchris]

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

[mucsi96]

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?

[Kepro]

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

[nasreddineskandrani]

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

[hevans90]

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

[nasreddineskandrani]

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

[hevans90]

@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!

[DiabolusExMachina]

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

[aldarund]

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

[cino893]

Try --maxWorkers=4 then.

[Kepro]

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

[gombek]

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.

[hevans90]

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

[empperi]

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.

[pfftdammitchris]

@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

[hevans90]

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

[timrobinson33]

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.

[empperi]

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.

[timrobinson33]

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.

[Cellule]

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

[timrobinson33]

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)

[empperi]

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.

[wickstargazer]

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

[JamesCatt]

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.

[duck-nukem]

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

[empperi]

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

[ahnpnl]

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

[JamesCatt]

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.

[alessioalex]

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 jest@25.3.x is taking 2-3 times more on Windows vs Linux to run some basic tests.