EugeneRoshal
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
tansy
Цитата:| Маленькая гипербола, небольшое преувеличение со стороны разработчика. |
Я проверял это на реальном xml файле с длинными совпадениями, взятом отсюда: https://uops.info/xml.html
При упаковке с -m5 -md128m -mcx время сжатия 1.8 секунды и 718K для fast bytes 128, 15 секунд и 688K для 2048, 35 секунд и 686K для 4095, 87 секунд и 683K при 4096, что эквивалентно отключению fast bytes. Даже выигрыш в 4% упакованного размера достается ценой восьмикратного падения скорости. За 5 процентов приходится заплатить 48 кратным снижением скорости.
Если убрать -mcx, получаем 756K и 0.8 секунды. То есть -mcx, в отличие от дальнейшего повышения fast bytes, на этом файле дает 5% выигрыша размера за двухкратное падение скорости, что, на мой взгляд, в некоторых ситуациях приемлемо. Причем -mcx куда универсальнее, чем подъем fast bytes, и дает вполне осязаемый выигрыш и на обычных текстах с короткими совпадениями. Оптимизация алгоритма, как правило, оказывается эффективнее, чем вывод параметров существующего алгоритма за сбалансированные пределы.
При этом отмечу, что выигрыш в 3 - 5% за счет fast bytes это очень нечастое явление, которое можно увидеть только на данных, где большинство повторов превышает длину fast bytes. Что, собственно, видно из вашего теста. Типичный же выигрыш совершенно незначительный, как и в вашем тесте.
Цитата:| Корпоры — это silesia, lukas_3d_dicom, ImageMagic |
По результатам видно, что там совпадений, превышающих длину fast bytes, скорее всего, мало. Поэтому увеличение этого параметра заметно ни на что не повлияло.
Цитата:| Поскольку у меня нет разрабатываемой версии Rar, и есть только один основной компрессор, который допускает очень длинные совпадения, я смоделировал его в Zstd - `tlen' |
Логично. Архиваторы ведь все внутри одинаковые. |
