Замена стандартной zlib

Вычитал на сайте «Linux для себя» совет, что замена стандартной библиотеки zlib на zlib-ng может дать ощутимый прирост производительности для многих утилит, которые используют сжатие на её основе. В частности, это касается броузеров и Web-клиентов. Стал искать benchmarkи, чтобы понять, насколько, и нашёл результаты тестирований, выполненных в прошлом году: https://aws.amazon.com/ru/blogs/opensource/improving-zlib-cloudflare-and-comparing-performance-with-other-zlib-forks/. Из них видно, что по-прежнему лидирует даже не zlib-ng, а версия zlib от Cloudflare, написанная ещё лет десять назад.
Решил поставить её на виртуальную машину (так как криво установленная zlib может нарушить нормальную загрузку системы). Собралось со второй попытки (нужно было дописать -fPIC в CFLAGS и SFLAGS), установилось. Вроде всё работает нормально, но оценить прирост скорости «на глаз» не представляется возможным. Потом, возможно, установлю на основной компьютер и сам погоняю тесты производительности.
Только вот один вопрос не даёт покоя: почему, если эти форки zlib дают такой прирост производительности, их не включают в дистрибутивы Linux изначально?

Вот и меня похожий вопрос давно беспокоит: почему годами не совершенствуют то, что в этом явно нуждается и продолжают оставлять всё как есть? Не хотят без особой необходимости вносить в систему (или её конфигурацию по умолчанию) кардинальные изменения, чтобы что-нибудь не сломать? Откуда такая консервативность?

Наиболее вероятный вариант. Знаешь шутку, чем опытный инженер отличается от неопытного? Опытный часто занимает позицию «работает — лишний раз не лезь».

Попытался поставить на основную систему, получил конфликт версий: Opera и Chromium требуют 1.2.9, а версия от Cloudflare определяется как 1.2.8. (Curl тоже перестал работать, но молча, без каких-либо пояснений.) Пришлось удалить.

А аналогичная модификация bzip2 тебе не попадалась? Просто сейчас она бы мне очень пригодилась: есть необходимость сжимать большое количество статики в bz2 (именно bz2) для последующей отдачи nginx'ом. Скрипт для этой задачи я уже написал, но при большом количестве сжимаемых данных он может работать весьма долго и было бы здорово, если бы этот процесс можно было немного ускорить (именно на уровне алгоритма bz2, распараллелить обработку файлов можно с помощью xargs).

Видел упоминания о pigzip и lbzip2, но они ускоряются за счёт многопоточности.

Всё же попробую их, это лучше, чем использовать xargs. Кстати, параллельный xz тоже есть: https://github.com/vasi/pixz.

Попробовал pbzip2. Столкнулся с тем, что он генерирует некорректные *.bz2-файлы: клиент игры, который загружает эти файлы с веб-сервера, выдавал ошибку проверки CRC-суммы. Попробовал lbzip2 — ошибка исчезла. Но куда больше меня поразила разница в скорости работы: файл размером 171 МБ pbzip2 сжал за 16.6 сек., в то время как lbzip2 сделал то же самое за 4.9 сек.! И это при том, что оба использовали все 4 ядра и 9-й уровень сжатия.