Why is pool: 'forks' not default?

[capaj]

From my very simple testing pool: 'forks' is slightly faster than the default pooling method. Initial run is like 500ms vs 300ms with pool: 'forks' for example. Why is it not the default?

I also tested vmThreads and those are the slowest on the initial run and fastest for subsequent runs.
I would say Vitest is mostly run on CI, so having forks as default would make sense in terms of performance

[sheremet-va]

Good question. We optimized forks pool in Vitest 1.0 and didn't look into performance differences yet, maybe it will be the default in the future.

[capaj]

Thanks, my testing was done on the sample project with like 2 unit tests. Would be nice to test the perf difference in a bigger project. Ideally one node.js and one react project at least.

[AriPerkkio]

Based on Tinypool's benchmarks Vitest's pool: 'threads' should be faster than pool: 'forks'.

• https://github.com/tinylibs/tinypool/blob/5e56748fd08f659c5d4825dd24dc9af09a93d95b/benchmark/isolate-benchmark.mjs

$ node isolate-benchmark.mjs 
Options: { THREADS: 8, ROUNDS: 2000, IS_BUN: false } 

Tinypool { runtime: 'worker_threads' } | START
Tinypool { runtime: 'worker_threads' } | END   10371 ms
Cooling down for 2s
................... ✓

Tinypool { runtime: 'child_process' } | START
Tinypool { runtime: 'child_process' } | END   12100 ms
Cooling down for 2s
................... ✓

Native node:worker_threads | START
Native node:worker_threads | END   9199 ms
Cooling down for 2s
................... ✓

[GrumpyLittleTed]

+1

I have just switched from Mocha to Vitest. I had V8 FATAL errors using code that used node-postgres native and node-libcurl because of the current default. It took me a while to investigate how vitest runs tests and to find the argument '--pool=forks' what was I needed so if it's also faster, as well as 'safer' it ought to be the default.

[AriPerkkio]

Maybe Vitest should indeed default to pool: 'forks' in next v2 major. There have been so many incompatibility issues with node:worker_threads and the code that users are testing.

In the guide/improving-performance.html page there could be a section describing how pool: 'threads' can provide faster test runs as communication between threads is faster than with processes. In my testing node:worker_threads are a bit faster than node:child_process when running thousands of threads/processes.

[AriPerkkio]

Continues at:

• fix!: change default pool to 'forks' #5047