>[оверквотинг удален]
>У LZ-based алгоритмов есть такое свойство что сжатие куда более ресурсоемко чем
>распаковка. У gzip сие тоже выражено, жмет медленнее чем распаковывает, особенно
>с -9 заметно. Чисто техническая заморочка. Дело в том что LZ
>ищет повторные данные в потоке. Поиск достаточно длинных совпадений - куда
>более ресурсоемко чем копирование кусков совпадений при распаковке. Тем не менее,
>фрукты с quicklz.com умудрились приблизить скорость сжатия к скорости распаковки. За
>это воздается достаточно скромным по степени сжатием, разумеется (если вы торопитесь,
>у вас нет времени поискать максимально возможное совпадение в огромном словаре
>на много мегов + применить добавочные техники - степень сжатия резонно
>страдает).

Алгоритм Лемпеля-зива не «ищет повторные данные в потоке», по крайней мере, в базовой реализации. Там используется другая схема работы: по мере чтения _битового_ потока ищется самый длинный совпадающий с текущим читаемым куском элемент словаря, записывается его код, затем «хвост», а новый элемент (найденный + хвост) попадает в словарь. Это сильно упрощённо, конечно. :)

Не изучал детально сорцы современных архиваторов, но, насколько я себе представляю возможность LZ* - используются разные настройки словаря, плюс возможно использование уже готового словаря ("мультимедийное сжатие RAR"). А так, простенький LZ-архиватор пишется на голом Си за два часа: час курения алгоритма, полчаса кодинг, полчаса дебаг. :)