Сжатие и упаковка - обсуждение и сравнения

[Titus]

Раньше каналы связи были гораздо хуже и винты меньше, а место под идентификаторы находили. А сейчас у всех интернет-эмули-пентевы-винты, а экономят на байтах (само улучшение сжатия как явление оченно хорошо). Парадокс...

Тут я с Витамином согласен. В погоне за несколькими десятками или сотнями байт, появляются дикие тормоза и долгий декранчинг, который жутко иной раз раздражает.

На мой взгляд, для игр и дем (там, где ждать пользователю точно не хочется много), депакер должен быть прежде всего мгновенным (как мой ;-)), а уж во вторую очередь должна учитываться эффективность.

[introspec]

Тут я с Витамином согласен. В погоне за несколькими десятками или сотнями байт, появляются дикие тормоза и долгий декранчинг, который жутко иной раз раздражает.

На мой взгляд, для игр и дем (там, где ждать пользователю точно не хочется много), депакер должен быть прежде всего мгновенным (как мой ;-)), а уж во вторую очередь должна учитываться эффективность.

Я думаю, что во всём нужна мера. Не в каждой ситуации скорость критична. Не в каждой ситуации быстрого распаковщика хватает, чтобы всё запихнуть.

[Titus]

Я думаю, что во всём нужна мера. Не в каждой ситуации скорость критична. Не в каждой ситуации быстрого распаковщика хватает, чтобы всё запихнуть.

Практика показывает, что в большинстве случаев долгие депакинги раздражают, и вполне можно запихнуть, если даже 100-200 байт будет лишними. Для исключительных случаев (а их меньшинство) можно воспользоваться более тормозным но сильным пакером.

Это надо прочувствовать то невероятное ощущение, когда начал загружать программу, и она за 2-3 секунды вся загрузилась и запустилась мгновенно.

Сравни, например, того же моего Murray Mouse и, и его же но пожатого другими пакерами или группами. Уже не говорю о монстрах типа Navy Seals.

[Blade]

На мой взгляд, для игр и дем (там, где ждать пользователю точно не хочется много), депакер должен быть прежде всего мгновенным (как мой ;-))

Для игр упаковка вообще не нужна. С DivIDE неупакованная игра загрузится быстрее, чем упакованная.

[Titus]

Для игр упаковка вообще не нужна. С DivIDE неупакованная игра загрузится быстрее, чем упакованная.

А вот и не факт, если депакер распаковывает быстрее, чем идет перброс данных из вашего IDE-контроллера в память.

[Blade]

Не распакует быстрее. Чтение с IDE это INIR:INIR, или раскрытый цикл с INI.

[Advertiser]

[alone]

mRIP при настройках FF FA FF FA FA FA FA FF FF - 29133 (депакер 220 байт)
ZXRar в режиме Rar, Header off и при тех же настройках - 29103 (депакер 386 байт)

Похоже, они не годятся для таких маленьких файлов из-за того, что надо хранить деревья для каждого файла.
Если файлы склеить в один, то ZXRar даёт 26077 при тех же настройках (для сравнения, WinRar - 24955).

[Titus]

Не распакует быстрее. Чтение с IDE это INIR:INIR, или раскрытый цикл с INI.

Значит разница будет копеечная, ибо распаковщики есть со скоростью от LDIR до LDIR*2.

[introspec]

mRIP при настройках FF FA FF FA FA FA FA FF FF - 29133 (депакер 220 байт)
ZXRar в режиме Rar, Header off и при тех же настройках - 29103 (депакер 386 байт)

Похоже, они не годятся для таких маленьких файлов из-за того, что надо хранить деревья для каждого файла.
Если файлы склеить в один, то ZXRar даёт 26077 при тех же настройках (для сравнения, WinRar - 24955).

Вот поэтому я и писал о пользе, по прежнему, от сравнительно простых упаковщиков. Но у меня не получается сделать 24955 в rar. ОК, мою прошлую цифру я привёл по совсем старому rar (оказалось, что у меня валялась третья версия в путях). Поставил 5.01, получилось 26195 (solid архив, т.е. то же самое склеивание). Ты без учёта заголовков как-то посчитал, да?

[alone]

Без заголовков. Это число WinRar выводит сам в пункте "Информация". У меня v3.50.