Это не техническая невозможность.
DotNetZip не выполняет многопоточную декомпрессию, потому что я никогда не реализовывал ее. MT сжатие было приоритетом; Я это сделал. Я просто не удосужился сделать декомпрессию MT. Сжатие обычно является более ресурсоемкой и дорогостоящей операцией, чем распаковка; это особенно верно для DEFLATE, типичного алгоритма сжатия, используемого в архивах ZIP, из-за требования поиска. Хотя я не эксперт по алгоритмам сжатия, я бы предположил, что подобная характеристика применима и к другим алгоритмам сжатия. Нет необходимости искать во время декомпрессии, и в результате декомпрессия, как правило, происходит относительно быстрее. По этой причине оптимизация декомпрессии в DotNetZip была менее приоритетной.
Примечание: параллельное сжатие в DotNetZIp выполняется для одного файла: предположим, у вас есть файл из 1000 блоков (для произвольной длины блока). DotNetZip подключит несколько потоков к сжатию, каждый поток сжимает один блок. Поскольку потоки компрессора работают независимо, возможно, что сжатие для блока 6 закончится, например, до сжатия для блока 4. Следовательно, основной поток отвечает за сборку сжатых блоков обратно в правильном порядке, а затем записывает их в выходной поток.
Таким образом, каждая запись (файл) в zip-архиве сжимается полностью, прежде чем библиотека начнет сжимать следующую запись. Существует очевидная возможность применить дополнительный уровень параллелизма при сжатии: параллельное сжатие нескольких записей. DotNetZip не делает этого сейчас. Такой подход к параллелизму имеет смысл, когда создаваемый zip-файл состоит из большего числа меньших файлов, тогда как параллельное сжатие, которое DotNetZip делает сегодня, имеет смысл, когда zip-архив содержит любое количество более крупных файлов (больше 512 КБ или около того).
Используя DotNetZip сегодня, на типичном современном ноутбуке, ЦП насыщается при сжатии больших файлов, которые имеют более 10 блоков или около того, где типичный размер блока составляет 512 КБ. Таким образом, добавление нового уровня параллелизма вообще не ускорит этот сценарий. Но это поможет сценарию сжатия, скажем, 70000 небольших файлов в один архив.