Yes, the default value is determined automatically, and it will always be slightly less than the number of CPU cores - there is always the main thread that manages the worker threads, and we have found that trying to utilize all the CPU cores is not worth the increase in overall CPU consumption.
The default value is derived from the number of virtual CPU cores:
- less than 4 virtual cores => 1 compressor
- 4 virtual cores => 2 compressors
- 8 virtual cores => 3 compressors
- 16 virtual cores => 6 compressors
- more than 23 virtual cores => 8 compressors
This said, our multi-core compression works with 512 KB long chunks (by default - can be changed using ZipArchive.Options.CompressorChunkSize
, but see my comment below), which means it does not provide any speed increase for short files.
We plan to do extensive benchmarking and publish a blog post soon outlining what speed increase you can expect in various scenarios. For now, I measured the duration of compressing 2 log files with an overall size of 410 MB:
Compression level 6 (default):
1 core … 45 seconds
2 cores … 25 seconds
3 cores … 17 seconds
Compression level 9 (highest):
1 core … 121 seconds
2 cores … 67 seconds
3 cores … 44 seconds
The time measurement indicates the total duration of the two ZipArchive.AddFile
method calls.
These measurements were done on a Dell laptop with Intel Core i7-3740QM CPU (4 CPU cores, 8 virtual cores) at 2.7GHz, 16 GB RAM and an SSD disk drive.
Using 4 cores still enhanced the speed noticeably, but for 5, 6 or more cores the additional speed increase was not worth the increased overall CPU usage.