ava: Forking for every test file is slow
Update: Blocked by #696
Seems like it is not quite good idea to spawn a fork for every test file. I have try’d fresh version of ava
in got and tests run time get worse (not to mention, that iTunes is getting icky while tests).
May be it is better to fork batched runners and/or have a concurrency
flag?
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Reactions: 3
- Comments: 44 (39 by maintainers)
We’re not and tbh it’s annoying that we’ll probably have too. Why can’t the system just pool the load for us instead of we doing it manually? I hate computers so much… Let’s experiement with what kind of number is optimal. I’m thinking
(require('os').cpus().length || 1) * 2;
.I have a very big project that I wanted to try ava on. After having the Activity Monitor (Mac OS X 10.11) open and seeing 50+
node
process, it brought my system to its knees. It’d be cool if there was some kind of limit.I think the biggest improvement will come from moving Babel to the main thread.
Definitely not speculation. Moving Babel to the main thread for tests created significant speed improvements. It stands to reason the same improvements could be realized by moving source transpilation out of the forks.
Already considered. See #791.
@spudly - I actually have a start on this already. I will post some code soon.
Basically, it needs to help identify
test.only
,test.serial.only
, etc.@sindresorhus: Or, a slightly more sane idea: Make a map of every file in our dependency tree mapped to it’s contents, then hook require to use those instead of the file system. Example:
If we uglified the files with “whitespace only” mode, it could totally* work!
*Probobly
Aren’t we setting some kind of limit of forks? We should probably not create more forks than there are CPUs.