Open voronin-ivan opened 9 months ago
Interesting! Do we know why it regressed so much in 18.13?
As for mitigations, easiest is probably just to avoid shelling out at all. Maybe walking the file system looking for .git
? And whatever the equivalent is for Mercurial and Sapling
Do we know why it regressed so much in 18.13?
I'm not sure, at first sight, only https://github.com/nodejs/node/commit/7b68c06988 is related to child_process
in that release.
easiest is probably just to avoid shelling out at all
Yes, that could be an option!
In my project, to mitigate this issue quickly knowing there is only one repo, I've made changes via patch-package π
FWIW, #14826 helps a bit before the findRepos
calls.
I found https://github.com/antongolub/git-root - I wonder if we should use that? I'd assume just fixing git
is enough as that's most used π
I found https://github.com/antongolub/git-root - I wonder if we should use that? I'd assume just fixing git is enough as that's most used π
Using git-root sounds good to me, but I'm not following how changing only findGitRoot
solves the issue, findHgRoot
and findSlRoot
are still expensive and always run. So it looks like we need to tackle them all or find a way to say to Jest that project(s) contain only git repo(s)
bah, of course... Mixing VCS-es sounds horrible, but I bet we'd break somebody if we looked for only looked for Mercurial and Sapling if we didn't find git roots.
I see that we find the VSC roots for every test run. I bet we could at least resolve those when normalizing config instead, so at least we'd only get the hit at the start of runs rather than every re-run.
https://github.com/jestjs/jest/pull/14826 should help a bit, btw
https://github.com/jestjs/jest/pull/14826 should help a bit, btw
Thank you, but I don't see much difference tbh because the most expensive operation is getRoute
, tried on commit e334898 that contains your changes.
node --inspect-brk ../jest/packages/jest/bin/jest packages/package-1/example.test.js --watch
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.
Version
29.7.0
Steps to reproduce
nvm use 20.10.0
npm ci
npm test packages/package-1/example.test.js -- --watch
You can reproduce this issue on any Node.js version starting at 18.13.0 by having a large number of
projects
.Expected behavior
--watch mode doesn't consume large amounts of resources and works fast.
Actual behavior
--watch mode is resource-intensive, works slowly and slows down the whole system.
Additional context
Why it's slow
findRepos is sluggish because of running a ton of
childProcess.spawn
under the hood (three processes per each project). It worked fast enough until Node.js version 18.13.0 was released, and this issue still persists even in the latest Node version (21.5.0).Performance footprint for 30s
node --inspect-brk ./node_modules/.bin/jest packages/package-1/example.test.js --watch
Node.js 18.12.1
Node.js 18.13.0 (and any later ones)
Possible ways to solve it
execa
, the current version that you use (5.0.0) is quite outdated, the latest is 8.0.1, there were some optimisation tweaksonlyOneRepo: boolean
orrepo: string
Environment