Declaration Syntax RemarksDotNetZip will use multiple threads to compress any ZipEntry, if the entry is larger than the given size. Zero means "always use parallel deflate", while -1 means "never use parallel deflate". The default value for this property is 512k. Aside from the special values of 0 and 1, the minimum value is 65536.
If the entry size cannot be known before compression, as with a read-forward stream, then Parallel deflate will never be performed, unless the value of this property is zero.
A parallel deflate operations will speed up the compression of large files, on computers with multiple CPUs or multiple CPU cores. For files above 1mb, on a dual core or dual-cpu (2p) machine, the time required to compress the file can be 70% of the single-threaded deflate. For very large files on 4p machines the compression can be done in 30% of the normal time. The downside is that parallel deflate consumes extra memory during the deflate, and the deflation is not as effective.
Parallel deflate tends to yield slightly less compression when compared to as single-threaded deflate; this is because the original data stream is split into multiple independent buffers, each of which is compressed in parallel. But because they are treated independently, there is no opportunity to share compression dictionaries. For that reason, a deflated stream may be slightly larger when compressed using parallel deflate, as compared to a traditional single-threaded deflate. Sometimes the increase over the normal deflate is as much as 5% of the total compressed size. For larger files it can be as small as 0.1%.
Multi-threaded compression does not give as much an advantage when using Encryption. This is primarily because encryption tends to slow down the entire pipeline. Also, multi-threaded compression gives less of an advantage when using lower compression levels, for example BestSpeed. You may have to perform some tests to determine the best approach for your situation.
See Also