> Хотя, что касается снаппи… Будем считать, что это было тёмное время.

Будем считать, что у кого-то в гугле NIH очень зудел.

> Нет, конечно, на сжатие он в 2 и более раз быстрее, но
> он ведь на распаковку медленнее zlib

Ващет быстрее. Но проблема в том что сравнимые алгоритмы либо
- Жмут лучше а распаковываются примерно как оно.
- Жмут примерно так же, но распаковываются быстрее.

Есть такая штука - pareto frontier. Грубо говоря, некая кривая, "степень сжатия vs скорость распаковки". Чем лучшем сжатие, тем, естественно, сложнее это потом быстро распаковывать из-за более продвинутого алгоритма и трюков формата. Проблема snappy в том что он находится не на этой кривой state of art'а, а где-то здорово под ней, не демонстрируя стоящих результатов вообще ни с каким выбором этих соотношений. И пойнт этого дизайна вызывает вопросы, если это нечто новое. Ну, предполагается что если кто-то новое дизайнит то оно чем-то лучше старого, чтоли. А так алгоритмов такого класса и без гугля было навалом, fastlz, quicklz, lzo, примерно в то же время lz4 вылупился, более длинный список - в lzbench можно посмотреть, "fast" кодеки.

> и жмёт при этом в 2 раза хуже.

Если это на примере тех XMLок с ratio в 4%, там очень специфичный результат. Когда инфо настолько избыточное, входной поток в декомпрессоре почти отсутствует и не рушит кэш, и алгоритм сильно втапливает. И чем лучше сжатие тем больше выигрыш на этом. Однако если коэффициент сжатия более вменяемый, скажем, 30-50%, такая халяве не наступает, входные данные достаточно интенсивно вымывают кэш, алгоритмы более-менее в равных условиях без дискриминаци по сжатию, и соотношения вообще совсем другие - snappy уделает zlib'а по скорости в пару раз на распаковке, просто потому что там декомпрессор тривиальный, в отличие от. Это неудачные/специфичные тестовые данные, сильно избыточнее типового случая.

> Но суть в том, что медленное ресурсоёмкое сжатие походит не везде и не для всего,

Поэтому для этого и были всякие LZO а потом и LZ4 - но у них есть фатальный недостаток: их накодил не гугл. Впрочем, этот недостаток оказался фатальным только для гугля - ну вот заурядный  и юзает в основном пара карманных проектов гугля.

> а так конечно может быть использовано любое сжатие где угодно. Но вот на уровне стандарта
> или формата файла zlib только в png.

Очень распостраненный формат сжатия на самом деле. Всякие gzip и ко - deflate. Или вон ресурсы и сэйвы HMMIII/IV. А на самом деле в силу халявной лицензии и существования дочерта лет - таки встречается в каждой дырке. И стандартной и не очень. В маздае installshield злибом сетапы паковал. "Installshield CAB". Это не то же самое что MS CAB, другой формат. Впрочем, последний тоже как один из вариантов алгоритма deflate допускает (называется MSZIP, но суть та же что и обычно). Эксплорер кстати .zip сразу жрет, куды ж он без поддержки inflate такой красивый? Или этого тоже мало?

Оно настолько распостранено - что классификаторы неизвестных файлов и проч даже ловят хидеры zlib и проч и выдают нечто типа "zlib-compressed data", как generic классификацию даже если они не знают формат лично. Либу нашару вывалили много лет назад - ей и попользовался все кому не лень, их легион. Достаточно попробовать zlib у себя в системе удалить целиком, посмотрев сколько от него depends...