wget конвертировать tgz файл в HTML

Как видите, большинство ответов пытается оптимизировать то, что возможно: количество переключений контекста и межпроцессный ввод-вывод. Причина в том, что это единственное, что вы можете легко оптимизировать здесь.

Теперь проблема в том, что потребность в ресурсах почти незначительна по сравнению с потребностью в ресурсах для декомпрессии. Вот почему оптимизации ничего не сделают быстрее.

Там, где его действительно можно было бы ускорить, это был бы модифицированный алгоритм un-gzip (т. е. распаковки), который исключает фактическое создание потока распакованных данных; скорее он только вычисляет количество новых строк в распакованном потоке из сжатого. Это было бы сложно, потребовалось бы глубокое знание алгоритма gzip (некоторая комбинация алгоритмов сжатия LZW и Huffman). Вполне вероятно, что алгоритм не позволяет существенно оптимизировать время распаковки с лайтингом, нам нужно знать только счетчики новой строки. Даже если бы это было возможно, по сути, должна была быть разработана новая библиотека распаковки gzip (она не существует, пока не станет известно).

Реалистичный ответ на ваш вопрос: нет, вы не можете сделать это значительно быстрее.

Возможно, вы могли бы использовать какую-нибудь распараллеленную декомпрессию gzip, если она существует. Он может использовать несколько ядер ЦП для распаковки.Если бы его не существовало, его можно было бы относительно легко разработать.

Для xz существует параллельный компрессор (pxz).