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 [email protected] 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