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 Investigate speed regressions #7110 as Jest speed regressions [v22 vs v23] on Windows for ALL problematic scenarios.
   where Re-run test in v23 is slower than v22 on Windows #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?
#7963 (comment)

[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 #7963 (comment)

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 Investigate speed regressions #7110 as Jest speed regressions [v22 vs v23] on Windows for ALL problematic scenarios.
   where Re-run test in v23 is slower than v22 on Windows #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

[Kepro]

so, we all know that issue is stupid NTFS :D

[empperi]

so, we all know that issue is stupid NTFS :D

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.

[lakmalniranga]

Since 2019 still we don't have fix for this :(

[csvan]

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.

[lakmalniranga]

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.

Well i already added it up there.

[jacobjuul]

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?

Can't figure out how to do this in CRA without ejecting.

[WhereJuly]

Can't figure out how to do this in CRA without ejecting.

Same for Vue CLI here.

[Jetskiis]

Any solutions for WSL for super slow runtimes? Tried installing globally, didn't improve it

[aderchox]

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.

[Sheepux]

Any solutions for WSL for super slow runtimes? Tried installing globally, didn't improve it

tried the npm global install and it didn't improve my issue.
However ... copying the project from the /mnt/c/etc... to /home/myproject resolved everything because there is no longer the NTFS issue. But that's just a second temp workaround (as i had to test a few things from ubuntu)

[cotneit]

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.

[Raskatan]

It's the same slowness for me after upgrading to Windows 11.

[nasreddineskandrani]

Confirmed: using the same windows i7 laptop got the test running 2.5x to 3.5x faster in one of my contracts project with WSL2

For Windows: use this video to setup wsl2 in vscode. You can also use wsl2 command line directly
https://www.youtube.com/watch?v=A0eqZujVfYU&ab_channel=ScottHanselman

Important: clone your project in your ubuntu folder (not /mnt) do not keep it in windows partition* and resetup node git in wsl2 vscode ...

[cnadolny2s]

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.

[Alino]

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.

[AAfetisov]

moving everything completely to linux partition sped things up 100x times at least. Cheers for the tip!

[acron0]

Still a problem

[Southclaws]

Is there an answer for actual Windows usage here? I'm not interested in using Linux or a Linux VM.

Does anyone know the underlying issue here? Is this a problem with Node's use of filesystem APIs or is it Jest itself doing something wrong?

[Kepro]

@Southclaws issue is slow NTFS so Windows is the issue

[empperi]

@Southclaws issue is slow NTFS so Windows is the issue

No it is not. If this was the case then all test runners would be as slow. And gazillion other apps. But they are not. But you are partly right: it's a combination of how NTFS works and what Jest wants to do. But saying NTFS is slow is just being ignorant and directs the conversation to wrong direction which isn't in any way productive.

[Southclaws]

Yeah I'm not convinced it's "jUsT a WiNdOwS iSsUe" and I've not really seen compelling evidence to back up the whole NTFS claims over the years, unless there are some deep dives I can go read that actually dig into the technical details. I've not had issues with any other language or high-throughput applications I've worked on so it seems to be something specific to Jest - perhaps it's doing more I/O operations than it needs to?

But saying NTFS is slow is just being ignorant and directs the conversation to wrong direction which isn't in any way productive.

100%, I'm interested in tooling that works for everyone, not just some people's favourite computers.

One thing I did check was the 8dot3name status on this system was enabled so I've disabled that which supposedly speeds things up, it seems to have had a positive effect so far.

[adrianv-synergy]

Has anyone tried performance on the new MS filesystem - ReFS ?
Currently available via a DevDrive on Win 11 (insider preview)

[System233]

Microsoft Windows [10.0.22621.2428]
node v18.16.0
jest 29.7.0

[mark-wiemer]

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 get the same behavior on Windows 10 and 11. Same machine, same project, same configs. Oh well.

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[mark-wiemer]

Still active and needs research

[hewelt]

Not sure if related to any of the problems mentioned, from my team's experience: we've seen huge difference in performance on running the tests on CI runners:' m5a.4xlarge (AMD) vs m6a.4xlarge (also AMD), like 2x/3x longer on m5a and much more flaky, they're both 16 virtual cores and not that far away in terms of cpu 🤷‍♂