Zstandard против XZ для больших пакетов (500 МБ и более)

Zstandard против XZ для больших пакетов (500 МБ и более) ⇐ Linux

1 сообщение • Страница 1 из 1

Anonymous

Zstandard против XZ для больших пакетов (500 МБ и более)

Цитата

Сообщение Anonymous » 01 май 2026, 14:16

Заголовок: Zstandard против XZ для больших пакетов (более 500 МБ) в пользовательском менеджере пакетов — реальные коэффициенты сжатия и компромиссы?
Тело:
Я разрабатываю собственный менеджер пакетов Linux (ядро написано на Rust). Сервер репозитория имеет ограниченное хранилище/процессор, поэтому интенсивное повторное сжатие на стороне сервера недопустимо. Я планирую, чтобы сопровождающие запускали команду публикации на своих машинах, которая подготавливает пакет и загружает его.
Моя философия — поддерживать единообразие экосистемы и избегать множества форматов. Текущий план — стандартизировать единый метод сжатия для всех пакетов.
Что я знаю:

Код: Выделить всё
```
zstd
```
значительно выигрывает по скорости распаковки и скорости сжатия.
Код: Выделить всё
```
xz
```
по-прежнему немного выигрывает по конечному сжатому размеру (особенно для очень больших двоичных объектов).

Что я пытаюсь решить:

Для огромных пакетов (например, игровые ресурсы, модели искусственного интеллекта, большие предварительно скомпилированные двоичные файлы — более 500 МБ в распакованном виде), can zstd -19 (максимальный уровень) реально соответствовать или достаточно близко к xz -9 в сжатом размере, чтобы оправдать полное удаление xz?
В частности, я ищу:

Реальные числа от любого, кто перенес репозиторий для больших двоичных файлов с xz на zstd. Сколько процентов размера вы на самом деле потеряли (или получили)?
Опыт обучения словарей: Кто-нибудь использовал предварительно обученные словари для zstd в контексте репозитория пакетов? Удалось ли сократить разрыв с xz? Стоила ли сложность эксплуатации того?
Влияние на конечного пользователя. Насколько заметна разница в скорости распаковки очень больших пакетов между xz и zstd на современном потребительском оборудовании? (Меня волнует время установки как часть UX.)
Особые случаи: существуют ли типы двоичных данных, где xz остается значительно лучше, поэтому стоит оставить его в качестве запасного варианта для сопровождающих с помощью явного флага (например, --keep-compression)?

Цель состоит в том, чтобы избежать преждевременной оптимизации, но также не зацикливаться на решении, которое в конечном итоге приведет к потере дискового пространства или пропускной способности. Если вы прошли через эту миграцию, чему вы научились?

1777634168

Anonymous

[b]Заголовок:[/b] Zstandard против XZ для больших пакетов (более 500 МБ) в пользовательском менеджере пакетов — реальные коэффициенты сжатия и компромиссы?
[b]Тело:[/b]
Я разрабатываю собственный менеджер пакетов Linux (ядро написано на Rust). Сервер репозитория имеет ограниченное хранилище/процессор, поэтому интенсивное повторное сжатие на стороне сервера недопустимо. Я планирую, чтобы сопровождающие запускали команду публикации на своих машинах, которая подготавливает пакет и загружает его.
Моя философия — поддерживать единообразие экосистемы и избегать множества форматов. Текущий план — стандартизировать единый метод сжатия для всех пакетов.
[b]Что я знаю:[/b]
[list]
[*][code]zstd[/code] значительно выигрывает по скорости распаковки и скорости сжатия.

[*][code]xz[/code] по-прежнему немного выигрывает по конечному сжатому размеру (особенно для очень больших двоичных объектов).

[/list]
[b]Что я пытаюсь решить:[/b]

Для [b]огромных пакетов[/b] (например, игровые ресурсы, модели искусственного интеллекта, большие предварительно скомпилированные двоичные файлы — более 500 МБ в распакованном виде), can zstd -19 (максимальный уровень) реально [b]соответствовать или достаточно близко[/b] к xz -9 в сжатом размере, чтобы оправдать полное удаление xz?
[b]В частности, я ищу:[/b]
[list]
[*][b]Реальные числа[/b] от любого, кто перенес репозиторий для больших двоичных файлов с xz на zstd. Сколько процентов размера вы на самом деле потеряли (или получили)?

[*][b]Опыт обучения словарей[/b]: Кто-нибудь использовал предварительно обученные словари для zstd в контексте репозитория пакетов? Удалось ли сократить разрыв с xz? Стоила ли сложность эксплуатации того?

[*][b]Влияние на конечного пользователя[/b]. Насколько заметна разница в скорости распаковки очень больших пакетов между xz и zstd на современном потребительском оборудовании? (Меня волнует время установки как часть UX.)

[*][b]Особые случаи[/b]: существуют ли типы двоичных данных, где xz остается значительно лучше, поэтому стоит оставить его в качестве запасного варианта для сопровождающих с помощью явного флага (например, --keep-compression)?

[/list]
Цель состоит в том, чтобы избежать преждевременной оптимизации, но также не зацикливаться на решении, которое в конечном итоге приведет к потере дискового пространства или пропускной способности. Если вы прошли через эту миграцию, чему вы научились?