Ripunzip uses rayon default thread pool, which I believe is one thread per logical core.
This is appropriate for cpu-bound work. However, unzipping spends a lot of time blocking on I/O, waiting for disk or network.
In such cases, you benefit from more threads than cores, so you can issue more iops in parallel. Particularly with SSDs that require many parallel I/O requests to saturate the hardware.
Ripgrep could either:
- provide a tuning argument like -j
- or auto tune the thread pool size (somehow)
- or both