Самый быстрый алгоритм / библиотека на распаковке

низкий размер архива и главное быстрая распаковка (возможно даже низкая нагрузка на проц)

«дёшево, хорошо и быстро» не бывает.

А вообще очевидный zstd очевиден.

Еще как бывает. gzip, bzip2, lzma ultra одни из самых тормозных. факт.

А подумать? Эти скорости - при нагрузке одного ядра на 100%. lz4 используется в ZFS как дефолтный алгоритм сжатия. Применяю на всех датасетах, разницы между «с» и «без» не заметил, потому что I/O в любом случае медленнее. В десятки раз.

Или zstd, да.

Еще как бывает. gzip, bzip2, lzma ultra одни из самых тормозных

«Дорого, плохо и медленно» конечно бывает :)

Дороги в России.

Нашел https://github.com/inikep/lzbench там тесты на одном ядре.

Ещё есть это. Но там нет zstd. Которое по ощущениям, как и lz4, легковесно (Пользовался в btrfs в качестве прозрачного сжатия).

lz4 гораздо хуже сжимает, чем zstd. «Низкий размер архива» не про него.

lz4hc уже немного получше жмёт, при практически той же скорости распаковки, что у «просто» lz4

memcpy()

Это верно. Я просто не приметил слона и ответил на это требование:

главное быстрая распаковка (возможно даже низкая нагрузка на проц)

С другой стороны, не ясно для чего оно ОП нужно, а в качестве «бесплатного» прозрачного сжатия lz4 - весьма неплохо:

% zfs get compressratio zpool0/system/gentoo
NAME                  PROPERTY       VALUE  SOURCE
zpool0/system/gentoo  compressratio  1.65x  -

P.S. Факт: Встроенная функция бекапа игры в Steam использует gzip с AVX ускорениями, не реально медленное и жрет все ресурсы процессора.

gzip, конечно, менее эффективен, чем вышеупомянутые zstd и lz4, но сам факт того, что алгоритм «жрет все ресурсы процессора» значит, что данная реализация хорошо использует возможности железа. Если бы другая реализация gzip пыхтела бы на одном ядре, не грузя его на 100%, то времени потребовалось бы гораздо больше.

ничего про нагрузку на проц, память.

Память надо бенчить на своих тестовых данных. Про lz4 разработчик пишет, что алгоритм не использует дополнительной памяти при распаковке, см. https://github.com/lz4/lz4/issues/661

А проц - чем больше он используется, тем лучше реализация алгоритма.

А проц - чем больше он используется, тем лучше реализация алгоритма.

так и запишем, кроме paq и lzma ничего нет, а то zstd/lz4/lzo меньше проц жрут

какой-нибудь самый обычный zip ultra сжал бы данные и быстрее и лучше и не загружая процессор, что gzip что bz2 те еще тормоза.

факт в том что многомиллионная(ардная?) компания valve ничего не делает.

Сравни, я почти на 100% уверен, что avx-версия сожмет данные намного быстрее

факт в том что многомиллионная(ардная?) компания valve ничего не делает.

можно подумать, что они сами этот компрессор писали - взяли наверняка обычный zlib-ng

bz2

у bz2 сейчас наверное вообще не осталось разумных ниш для применение, lzma и zstd все съели