jest: Re-run test in v23 is slower than v22 on Windows

💥 Regression Report

Re-run test in version 23 is significantly slower than version 22 on Windows

Last working version

Worked up to version: 22.4.4

Stopped working in version: 23.0.0

To Reproduce

These two repos only contains a test file jest.test.js and install different jest version.

test('foo', () => {
  expect('foo').toBe('foo')
})

run yarn test --watchAll --env=node

then, press Enter to trigger a test run In v22, it takes about 0.05s, but over 2s in v23

When editing test file to trigger re-run, v22 can finish in 0.5s but v23 usually takes close to 3s

Run `npx envinfo --preset jest`

  System:
    OS: Windows 10
    CPU: x64 Intel(R) Core(TM) i5-5250U CPU @ 1.60GHz
  Binaries:
    Yarn: 1.7.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD

Update: It is an issue only on Windows, test it on Linux, just a little bit slower but acceptable.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 35
Comments: 48 (19 by maintainers)

Most upvoted comments

Similar experience when trying to upgrade jest on OS X. To test the performance, we run jest --watch then a option Using 22.4.4, this takes 20 seconds Using 23.0.0, this takes 58 seconds So the slowdown happens with the version 23 major release. In both cases, we make sure snapshots are updated and all changes are committed (git status is clean). Will try to create a minimal reproducible repo if I have time.

paradite on Sep 25, 2018

@SimenB The slowdown happens on OS X too.

deleteme on Sep 13, 2018

This looks like it might be cache related, as running @Isaddo’s test23 repo with: yarn test --watchAll --env=node --no-cache has almost instantaneous re-runs.

benhamlin on Oct 29, 2018

if someone hit this issue i edited my previous comment: https://github.com/facebook/jest/issues/6783#issuecomment-450509214 so solution 1 is now a nice workaround (when jest v24 is released) => for those that are running in intellij, webstorm, vscode, command-line test for one file just add --runInBand

I am really busy these dayz so when i have time i’ll continue with --experimental-worker investigation if no one solve it before.

nasreddineskandrani on Sep 28, 2019

It is actual for MacOS too “jest 23.4.2” is slower than “jest 22.1.4” at most 80%

deerares on Aug 10, 2018

You need to run node with --experimental-worker for it to be available.

$ node --version
v10.14.1
$ node -p "require('worker_threads')"
internal/modules/cjs/loader.js:582
    throw err;
    ^

Error: Cannot find module 'worker_threads'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:580:15)
    at Function.Module._load (internal/modules/cjs/loader.js:506:25)
    at Module.require (internal/modules/cjs/loader.js:636:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:96:20)
    at Object.runInThisContext (vm.js:303:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at evalScript (internal/bootstrap/node.js:582:27)
$ node --experimental-worker -p "require('worker_threads')"
{ isMainThread: true,
  MessagePort: [Function: MessagePort],
  MessageChannel: [Function: MessageChannel],
  threadId: 0,
  Worker: [Function: Worker],
  parentPort: null }

SimenB on Dec 30, 2018

I did the test with the repo.s from the guy that opened this issue: https://github.com/Isaddo/testjest22 and https://github.com/Isaddo/testjest23

When i tested => no problem in my machine because my first run was < 1sec

Explanation

=> Running in band in the case of the issue will make the tests run faster as wanted.

in v22 jest the condition to run in band was: tests.length <= 1

and in v23 jest the condition to run in band became: tests.length <= 1 && timings.every(timing => timing < SLOW_TEST_TIME) where SLOW_TEST_TIME = 1 sec

the condition was changed to fullfill the need of https://github.com/facebook/jest/issues/6599 but it breaks the scenario of the dev that opened this issue since in his machine the first run was > 1sec and with the UI for workers between runs it’ll never comeback under 1sec.

note: with --no-cache arg the timings array is always empty so .every( ) return true and it run in band that’s why the --no-cache was solving the problem.

Possible Solutions

I need your input about which direction for a fix we want to take. I see multiple options:

Solution1: (That’s the best option in my opinion) tell devs if you want a fast test run on a single file as in v22 then pass --runInBand arg (i always did it this way with my team) edited: 2019-01-26 jest v24 contain a fix so use --runInBand it ll be fast as v22

Solution2: (not a robust solution in my opinion but it may work to close this issue) change the SLOW_TEST_TIME from 1sec to 3sec as it was before and keep the condition with the timing even for one single test file

Solution3: (not ideal since the dev needs to set manually as opposite to now where it’s auto) Remove the timing concept and keep only the condition tests.length <= 1 and make runInBand arg a boolean that can be set to false eventually. => which if set to false if i am not wrong will fulfill @gaearon needs mentionned here: https://github.com/facebook/jest/issues/6599#issue-337531475.

@thymikee waiting for feedback 😃 if you see other solutions let me know

nasreddineskandrani on Jan 26, 2019

Is there any update with this? It seems like the slowness is also on Linux as well. My team has been experiencing the same issues with slowness to the point where a dev is looking into porting back to mocha? Would love to not have to switch from Jest ❤️ if this is something that may be addressed in a later release.

ZachStoltz on Sep 5, 2018

Can confirm 23 is much slower than 22 on re-running tests on Windows using Typescript and ts-jest.

23.4.1 adds ~3 seconds to a 3ms noop test

22.4.4 runs test re-runs as fast as expected

mpseidel on Aug 7, 2018