Ru-Board.club
← Вернуться в раздел «Программы»

» Архиваторы. Сравнение сжатия

Автор: Anteus
Дата сообщения: 26.07.2012 14:46
Бывает сжимаю большое количество информации, для её последующего хранения
По скорости и сжатию нравиться 7z (именно в их формат он сжимает)
А так всегда пользуюсь WinRAR
Автор: Shuld
Дата сообщения: 26.07.2012 16:04
В WinZip 16.5 анонсировано значительное ускорение сжатия силами видеокарты.
Но на практике, похоже не очень:
http://forums.overclockers.ru/viewtopic.php?p=9567408#p9567408

А из новых архиваторов очень интересен ZCM5 v.050a (2012.06.04).
Здесь можно посмотреть тесты автора, в том числе по различным типам данных:
http://heartofcomp.altervista.org/MOC/MOCA.htm
А здесь скачать:
http://heartofcomp.altervista.org/ZCM/home.htm
Навскидку попробовал (из командной строки). Мои результаты примерно такие же. (Сжимает сильнее CCMx/CCM, и тем более WinRAR/7z/FreeArc, за вменяемое время) Регулировка сжатия аналогично CCMx/CCM, paq8, по большому счету ее нет - можно немного изменить степень сжатия при увеличении занимаемого ОЗУ и практически за то же время.
Автор: muzf
Дата сообщения: 30.07.2012 13:11
Shuld
Твоё тестирование http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#19 к сожалению некорректно и неполно.
1. Во freearc сейчас сжатие jpeg сломано, packarc(packjpg) вызывается не напрямую а через precomp, что практически не сжимает jpeg, это видно по результатам. И вызывается он теперь через -m9j а не -mx (читать отсюда http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1580#17 )
2. Нет собственно самого packarc (packjpg)
3. На кой чёрт тестировать .mht ? Кто-то его сейчас пересылает или бэкапит в громадных количествах ?
Автор: Shuld
Дата сообщения: 30.07.2012 18:59
Идеала не существует, и никакой тест не будет "полным".
В своих тестах я выкладываю наиболее значимые, по моему мнению, результаты. А поскольку все люди разные, да, одному будет не хватать одного, другому - другого.
Но всегда можно проделать тесты самому.
Я смог найти достоинства paq8pxd только на файлах .mht. Поэтому включил в результирующую таблицу. Иначе смысла в paq8pxd вообще не было бы видно. А как еще надо было сделать?
Сделайте хороший тест, как Вы его представляете, и опубликуйте. А то их (тестов) по архиваторам на русском языке вообще мало (тема неактуальная?). Я за 2012 год только эти знаю:
2012.05.04 Обзор и тест популярных архиваторов: 7-Zip, Power Archiver, WinRAR, WinZip
http://www.almodi.org/raznoe-po/obzor-i-test-populyarnich-archivatorov-7-zip-power-archiver-winrar-winzip

2012.03.02 Тест архиваторов
http://bunker27.blogspot.com/2012/03/blog-post.html

2012.01.11 Тестирование архиваторов: WinRar vs 7zip vs Hao Zip
http://yes.km.ua/index.php?option=com_content&view=article&id=107:testing-the-archives-winrar-vs-7zip-vs-hao-zip&catid=37:computers-soft&Itemid=61

А про такую "новость 2012 года", как эта, даже говорить не хочется:
http://f1.of.by/news/53-testirovanie-arhivatorov.html
Желающие могут сравнить с
http://article.techlabs.by/full/44_218.html
Автор: muzf
Дата сообщения: 31.07.2012 11:59
Меня архиваторы (как наверное и всех) интересуют только в двух случаях - снижение объёма пересылки и для бэкапа.
Как у обычных пользователей, основной контент который нужно бэкапить и который сжимается - это jpg и mp3. Первый во freearc поломан, второго из коробки нет. PAQ хороши, но навряд кто-то в здавом уме будет сжимать им 200gb jpg по 200сек каждую. Для этого лучше подходят более быстрые StuffIt (jpg), WinZip (jpg), packarc (jpg+mp3) ну и freearc как оболочка для любого. Причём режим -sync из всех поддерживает только freearc.
Причём автор freearc, этот замечательный человек, не горит желанием исправлять эти баги, вернуть нормальное сжатие jpg, добавить mp3 в коробку.
Автор: Bulat_Ziganshin
Дата сообщения: 31.07.2012 12:20
а как этот замечательный человек может добавить mp3? внешний упаковщик в power pack вероятно есть
Автор: muzf
Дата сообщения: 31.07.2012 13:12
Взять и волевым решением добавить например packarc в дефолтный ini для jpg/mp3. За счёт параллельного запуска freearc сразу начнёт рвать всех по скорости сжатия jpg/mp3 во всяких мультимедийных тестах сжатия. Чтобы каждый не изобретал велосипед (свой .ini) взял и начал им пользоваться. Чтобы когда захотелось переслать фотки с очередного отпуска на несколько гигабайт, использовали простой и эффективный freearc sfx, а не глючный StuffIt (в sfx не умеет сжимать jpg), глючный winzip (sfx не более 2гб и не умеет сжимать jpg при sfx).
В powerpack нет внешнего упаковщика mp3. Да и непонятно что делать с powerpack - поставился он c:\Program Files (x86)\FreeArc\PowerPack\ , внутри нет arc.exe и непонятно, то ли копировать всё в основной FreeArc\bin то ли оставить всё на месте.
Автор: Shuld
Дата сообщения: 31.07.2012 16:58

Цитата:
Меня архиваторы (как наверное и всех) интересуют только в двух случаях - снижение объёма пересылки и для бэкапа.
Как у обычных пользователей, основной контент который нужно бэкапить и который сжимается - это jpg и mp3.

То-то и оно!
Я jpg и mp3 не сжимаю. Вообще!
В моих бэкапах .doc, .pdf и .mht!!! (и архивы).
Автор: cuneiform
Дата сообщения: 13.09.2012 13:00
Господа "архивариусы", кто может дать совет по сжатию ISO-файлов размером от 1 (часто) до 7 Гб (редко) ?

Вопрос не надуманный - это Digitale Bibliothek, примерно 120 Гб. Скачивается с торрентов, а там архивирование запрещено правилами. Хотя можно выигрыш в траффике получить до 10 раз. Например, медицинская энциклопедия занимает в ISO 2 Гб, а при сжатии - всего 200 Мб. - Глупо хранить всю библиотеку в исошниках. Сотни CD.

Какой выбрать алгоритм с учетом потерь времени? - Я лично склоняюсь в пользу gzip.

Альтернативно - 7zip ---> LZMA(2) или PPMd. Какие детально выбрать тогда лучше опции архивирования в 7zip?

Не знаю также, какой из них лучше и какой взять конкретно архиватор.
Может кто-то просто rar посоветует.

Конечно, есть и принципиальное решение - отказ от .iso в пользу .daa -- выигрыш по сжатию до 10 раз.
Автор: cuneiform
Дата сообщения: 26.10.2012 19:05
Так никто и не ответил, чем и как сжимать и в каких режимах ISO-файлы.
А вопрос-то практикой заточен был.
И китайцы дали на него ответ, создав формат daa (проприетарный).
Не было б проблемы - не было б этого формата.

Всем понятно, что исошники нельзя без сжатия хранить, все их чем-то как-то сжимают.

Вот я и спросил, какие режимы вы считаете оптимальными для больших
исoшников, что б ждать не более ~10 мин.

У кого сотни исошников, тот должен об этом думать.


Автор: Engaged Clown
Дата сообщения: 26.10.2012 20:51
cuneiform
Как вариант - REP/SREP
http://encode.ru/threads/1250
http://encode.ru/threads/583
http://encode.ru/threads/1376
http://encode.ru/threads/1362
Автор: persicum
Дата сообщения: 27.10.2012 10:40
Недавно я качнул изошку ISZ - то есть саму по себе сжатую... Говорят, ее можно напрямую цеплять к демону... Не покатит?
Такие сжатые ISZ производит прога UltraISO.
Автор: Astron
Дата сообщения: 21.11.2012 10:03
Господа! Посоветуйте! Пользуюсь MacBook Pro Late 2011, OS X Mountain Lion 10.8.2, архиватор Keka 1.0.3. Cобираю архив софта себе, и часто бывает такая ерунда - упаковываю непосредственно программу Sample.app в архив Sample.app.7z например, и после распаковки она не хочет запускаться. Создается впечатление, что процесс упаковки нарушает целостность каких-то важных данных. Иногда приходится сначала "заворачивать" прогу в zip, а потом дожимать 7z - но это не решение проблемы. Недавно приобрел софт iPack, к которому прикрутил консольный RAR - пока не тестировал. Сорри за оффтоп.
Автор: Teemoor
Дата сообщения: 26.11.2012 16:55
Уважаемые форумчане,

не поделитесь версией FreeArc в которой корректно работает сжатие изображений типа jpg, jpeg? На сайте версия 0.666 (20 мая 2010 г.) - она насколько я понял некорректно работает с изображениями. Очень нужно для архивирования огромного объема семейных фотографий.
Автор: muzf
Дата сообщения: 26.11.2012 17:18
Astron
Нет такой официальной. Текущие версии Frearc используют Precomp, в котором баг определения размера данных внутри jpeg. Можно изменить ini и прописать вручную packarc на упаковку и распаковку, но вот Булат ленится сделать это в официальном ini до исправления бага в Precomp.
Автор: Teemoor
Дата сообщения: 26.11.2012 18:12
muzf не подскажите как и где надо это прописать? Заранее премного благодарен.
Автор: Shuld
Дата сообщения: 02.12.2012 05:33
Тест архиваторов на декабрь 2012 года

Участники теста: WinRAR 4.20 (14 июня 2012), 7z 9.22b (18.04.2011), FreeArc 0.67 (28 ноября 2012).
Последняя версия архиватора 7z 9.30alfa по времени и степени сжатия практически не отличается от 9.22b. Результаты тестирования с предыдущими версиями архиваторов можно посмотреть в тесте за февраль 2012
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6.
Результаты теста той же папки с файлами, с новыми версиями архиваторов:

График с осями «время» и «размер архива»:

Каждый маркер обозначает один результат теста. Результаты разных архиваторов обозначены разными цветами. Слева вверху – быстрые режимы, справа внизу – максимальные режимы. Маркер, который находится одновременно левее и ниже – лучше того, который находится правее и выше.
График приведен в логарифмическом масштабе по оси времени, поскольку для FreeArc-а диапазон скоростей работы отличается в 40 раз, что плохо передается в линейном масштабе.
На графике без изменения перенесены результаты предыдущего теста, с сохранением цвета графика, и добавлены свежие результаты.
Зеленый цвет принят для стандартных методов FreeArc, серый цвет – для экспериментальных –m81…-m89 (2011 г), коричневый цвет – для экспериментальных –m81…-m89 (2012 г).

Начнем с WinRAR-а.
Версия 4.20 стала заметно быстрее версии 4.11. При этом методы сжатия «обычный», «хороший» и «максимальный», как и раньше, практически не отличаются друг от друга. Можно даже сказать, что у WinRAR-а только два метода сжатия: «скоростной» и «остальные». Тем не менее, теперь во всех методах сжатия он лучше быстрых методов у 7z.

7z
На сильных методах сжатия лучше и медленнее, чем WinRAR.

FreeArc
Значительно улучшился метод –m1. Он стал одновременно быстрее и плотнее.
Остальные методы изменились слабо, причем –m2/m3/m4 скорее в худшую сторону. Они стали быстрее, но хуже по сжатию (на этом наборе данных).
Новые варианты методов –m81…-m89 (коричневый цвет на графике) стали чуть быстрее при примерно такой же степени сжатия как и раньше.
Все методы –m81…-m89 требуют много памяти (2 ГБ и более) и проверены на компьютерах с процессорами i3-530 (2 ядерный, 4 поточный) и двухядерным E6750 (2.66GHz). На 8-ми ядерных процессорах не проверялись.
Для того, чтобы использовать методы –m81…-m89 необходимо скачать файл arc.ini, запакованный в архив (8КБ): Скачать arc2012-12-02.zip с WebFile.RU и записать его поверх стандартного arc.ini, который должен находиться в том же каталоге, что и Arc.exe (под Windows). Данный файл arc.ini совместим ТОЛЬКО с версиями архиватора 2012 года, и не совместим с версиями до 2011 года включительно. Для версий 2011 года нужно скачать файл от старого теста за февраль 2012 (ссылка в начале).
Следует иметь ввиду, что самые быстрые методы –m1, –m2, –m81…-m84 работают на скоростях, сравнимых или быстрее современных винчестеров. Поэтому время сжатия этих методов в реальных условиях может примерно совпадать. Эффект от этих методов может быть виден на компьютерах с raid-массивами и/или SSD-винчестерами. Желающие также могут попробовать экспериментальный метод –m80 (есть в последнем arc.ini), который еще быстрее. Время сжатия 2,55 с, размер архива 452 209 560 байт.
Скачать последнюю версию FreeArc можно отсюда: http://freearc.org/Download-Alpha.aspx
Для ассоциации с папками и файлами рекомендую поставить следующие галочки в настройках:

Методы сжатия –m81…-m89, после установки файла arc.ini, можно указывать в меню сжатия:

После указания какого-либо из методов вручную один раз, в последующем, этот метод будет доступен в открывающемся меню, кнопка справа в строке «сжатие».
Автор: Shuld
Дата сообщения: 02.12.2012 12:48
Увидеть, успевает ли винчестер за архиватором FreeArc, можно следующим образом:
Нажимаем Ctrl+Alt+Del и запускаем диспетчер задач.
В диспетчере выбираем вкладку "Быстродействие".
Начинаем архивировать что-нибудь большое.
Когда винчестер не успевает, процессор (ЦП) простаивает:

Если винчестер успевает, процессор загружен по полной:

В "хронологии загрузки ЦП" будет столько графиков, сколько потоков (ядер) у процессора.
В данном случае скриншоты показывают работу 2-ядерного процессора.
Автор: Bulat_Ziganshin
Дата сообщения: 02.12.2012 14:11

Цитата:
Когда винчестер не успевает, процессор (ЦП) простаивает:

цп простаивает также и в том случае когда архиватор не может полностью распарралелиться. к примеру rar у меня загружает цп примерно наполовину (при сжатии с рам-диска)


Цитата:
Значительно улучшился метод –m1.

к этим работам меня сподвиг ты. кстати жаль что ты тогда же в феврале не протестировал изменения

и ещё - без быстрых методов nanozip эти тесты неполноценны. попробуй методы -cf, -cF, -cd, -cD, -co. объём используемой памяти настраивается опцией -mem1.5g
Автор: Astron
Дата сообщения: 11.12.2012 17:53

Цитата:
Нет такой официальной. Текущие версии Frearc используют Precomp, в котором баг определения размера данных внутри jpeg. Можно изменить ini и прописать вручную packarc на упаковку и распаковку, но вот Булат ленится сделать это в официальном ini до исправления бага в Precomp.

Получается, проблема все-таки в выборе архиватора? 7-Zip косячный? С RAR проблем не будет?
Автор: muzf
Дата сообщения: 11.12.2012 17:59
Astron
Причём здесь 7-zip ?
Precomp используется в Freearc.
Автор: muzf
Дата сообщения: 25.03.2013 17:56
Решил провести своё сравнение архиваторов на уровень сжатия и на скорость сжатия/разжатия на образе VHD файле с установленным внутрь CentOS, размер 3 039 549 952 байт.
Участники теста: Winrar4.20 (x64, 14.06.2012), 7-Zip 9.30 alpha (x64, 26.10.2012),FreeArc 0.67 (x32, 12.12.2012, precomp043)
i7-860 (22x154), 8 потоков, 16gb, win7 x64, все тесты проводились на RAM диске, TEMP там же (использовался только в precomp).
У Winrar принудительно включен Solid режим, у остальных он включен по умолчанию.




Итак, поехали. Метод Deflate и Deflate64, используемый в zip - аутсайдерах, и по скорости, и по сжатию. Deflate64 чуть лучше Deflate, поэтому можно всегда использовать его, кроме случае если архив планируется открывать встроенными средствами в WinXP. Самый медленный Deflate сжимает хуже чем самый быстрый 7z-LZMA/RAR, при этом в 50 раз медленее. Распаковка около 30% медленее чем RAR.

7Z PPMd на данном наборе бесполезен, так как это не текстовые данные. Тем более он однопоточный. Сильно медленее всех по расжатию.

7Z Bzip2 (да и просто Bzip2) - получше чем Deflate(zip), побыстрее, но страдает медленной скоростью. Нет смысла использовать сжатие выше среднего.

7Z Lzma - нет никакого смысла использовать LZMA, когда есть более быстрый LZMA2, не зря его включили по умолчанию в 7z 9.30, хоть он и даёт сжатие на 1% меньше LZMA. Самый быстрый LZMA2 на 4% лучше чем самый быстрый Zip, и на 3% лучше самого сильного zip (который в 20 раз медленнее). Максимальный LZMA2 сжимает в 1.5 раза быстрее чем средний ZIP и лучше на 9%. Удивительно, но увеличение степени сжатия приводит к более быстрой распаковке, которая в среднем 3 раза медленнее чем у RAR и похожа на Bzip2. Видимо распаковка в отличие от Winrar здесь на распаралелена.

Rar - его кривая похожа на 7Z LZMA2, то есть используется этот же алгоритм. Режим -m1 (Fastest) медленее и хуже самого быстрого LZMA2, RAR -m2 (Fast) полностью совпадает с 7z LZMA2 -m3 (Fast), при этом более сильных (и долгих) режимов в Winrar просто нет. 200Mb/sec на распаковку в любых режимах.

NanoZip не впечатлил, да, чуть лучше чем простые режимы FreeArc, но хуже чем -m8*. Да, жмёт на 1/10% сильнее всех, но распаковывает также долго, в реальной жизни это бесполезно. Не имеет режима --sync как в Freearc для поддержки бэкапов, позволяющего пережимать только изменённые файлы.

Freearc, особенно -m8*, лидирует во всех режимах, показывая непревзойдённые результаты скорости на быстрых режимах, пересекаясь с максимальным LZMA2 где-то в районе -m45. На самых сильных режимах видны удивительные вещи - High медленнее Maximum, который медленее Ultra! Видимо получая больше памяти, Freearc ускоряется с увеличением степени сжатия. Режим precomp (m5p) сжимает лучше всех, но самый долгий, и в практических ситуациях нет смысла его использовать. m9j с поиском jpeg я вообще не дождался, он повис на 10% и через 2 часа я его выключил.
-m9x абсолютно бесполезен, медленнее всех (кроме precomp), жмёт как -m7 High, ускорения при распаковки не замечено. По скорости расжатия как -m5, но в 2 раза медленнее его на сжатии.

Freearc -m80-m89, эти экспериментальные режимы действительно оказались на эти данных самыми лучшими, в том числе и по скорости разжатия, все кроме -m89 показывают до 420Mb/sec.
-m80 жмёт на уровне быстрых Rar/LZMA2, но в 10 раз быстрее (более 700Mb/sec на сжатие и более 1Gb/sec на распаковку!).
-m81 сжимает на скорости 500Mb/sec и при этом сильнее чем Winrar max (в 12 раз быстрее), и в 4 раза быстрее похожего freearc -m3.
-m85 или -m86 - самые практичные для бэкапов, жмут практически со скоростью HDD (130 и 60Mb/sec соответственно), при этом жмут лучше абсолютно всех других архиваторов, на уровне -m7 (High, который в 5-10 раз медленнее).
-m87 хорош для плотного но довольно быстрого сжатия (22Mb/sec), при этом жмёт лучше -m7 (High).
-m89 по скорости как -m5, но жмёт лучше. Но спорный, так как есть тот же Ultra всего в на 14% медленее и жмёт сильнее, хоть и требует 2гб для распаковки. Но в отличие от -m5 и Ultra режимов, в 3 раза быстрее на распаковке, 250Mb/sec. То есть подходит как замена неработающему ассиметричному режиму.
Автор: Shuld
Дата сообщения: 26.03.2013 19:27
muzf

Цитата:
RAM диске


Какой программой?

Добавлено:
Вот в этих экспериментах
http://pc-hard.ru/softarticles/77-ramdisk-dataram-softperfect-qsoft-sravnenie.html
признается, что самый быстрый - qSoft RAMDisk Enterprise.
Автор: Bulat_Ziganshin
Дата сообщения: 26.03.2013 20:40
проверил, мой быстрее

[more]QSoft NTFS
I:\>for %a in (12 13 14 15 16 17 18 19 20 21 22 23 24) do read -b%a dll4g.rep96m256.dll
Buffer 4 KB. dll4g.rep96m256.dll 3406mb: time 28.383192 seconds, speed 120.024689 mbytes/sec
Buffer 8 KB. dll4g.rep96m256.dll 3406mb: time 13.812502 seconds, speed 246.637706 mbytes/sec
Buffer 16 KB. dll4g.rep96m256.dll 3406mb: time 7.543254 seconds, speed 451.619929 mbytes/sec
Buffer 32 KB. dll4g.rep96m256.dll 3406mb: time 3.940161 seconds, speed 864.605322 mbytes/sec
Buffer 64 KB. dll4g.rep96m256.dll 3406mb: time 2.265857 seconds, speed 1503.485487 mbytes/sec
Buffer 128 KB. dll4g.rep96m256.dll 3406mb: time 1.497898 seconds, speed 2274.309350 mbytes/sec
Buffer 256 KB. dll4g.rep96m256.dll 3406mb: time 1.093410 seconds, speed 3115.649581 mbytes/sec
Buffer 512 KB. dll4g.rep96m256.dll 3406mb: time 1.265459 seconds, speed 2692.053237 mbytes/sec
Buffer 1 MB. dll4g.rep96m256.dll 3406mb: time 1.182608 seconds, speed 2880.653109 mbytes/sec
Buffer 2 MB. dll4g.rep96m256.dll 3406mb: time 1.274818 seconds, speed 2672.290087 mbytes/sec
Buffer 4 MB. dll4g.rep96m256.dll 3406mb: time 1.433706 seconds, speed 2376.138514 mbytes/sec
Buffer 8 MB. dll4g.rep96m256.dll 3406mb: time 1.548244 seconds, speed 2200.353865 mbytes/sec
Buffer 16 MB. dll4g.rep96m256.dll 3406mb: time 1.556330 seconds, speed 2188.920848 mbytes/sec


I:\>for %a in (12 13 14 15 16 17 18 19 20 21 22 23 24) do read -b%a dll4g.rep96m256.dll
Buffer 4 KB. dll4g.rep96m256.dll 3406mb: time 27.945118 seconds, speed 121.906220 mbytes/sec
Buffer 8 KB. dll4g.rep96m256.dll 3406mb: time 15.188603 seconds, speed 224.292103 mbytes/sec
Buffer 16 KB. dll4g.rep96m256.dll 3406mb: time 7.760376 seconds, speed 438.984342 mbytes/sec
Buffer 32 KB. dll4g.rep96m256.dll 3406mb: time 4.219895 seconds, speed 807.291082 mbytes/sec
Buffer 64 KB. dll4g.rep96m256.dll 3406mb: time 2.498508 seconds, speed 1363.487390 mbytes/sec
Buffer 128 KB. dll4g.rep96m256.dll 3406mb: time 1.603155 seconds, speed 2124.987083 mbytes/sec
Buffer 256 KB. dll4g.rep96m256.dll 3406mb: time 1.076372 seconds, speed 3164.969283 mbytes/sec
Buffer 512 KB. dll4g.rep96m256.dll 3406mb: time 0.888965 seconds, speed 3832.190297 mbytes/sec
Buffer 1 MB. dll4g.rep96m256.dll 3406mb: time 0.751262 seconds, speed 4534.615390 mbytes/sec
Buffer 2 MB. dll4g.rep96m256.dll 3406mb: time 0.735302 seconds, speed 4633.037890 mbytes/sec
Buffer 4 MB. dll4g.rep96m256.dll 3406mb: time 0.958381 seconds, speed 3554.622824 mbytes/sec
Buffer 8 MB. dll4g.rep96m256.dll 3406mb: time 1.056777 seconds, speed 3223.654656 mbytes/sec
Buffer 16 MB. dll4g.rep96m256.dll 3406mb: time 1.032459 seconds, speed 3299.583435 mbytes/sec

Product name: RamDisk Plus / RamDisk
Product version: 10.0.1.0

File name: SscRdCpa.Cpl
Description: RamDisk control panel device manager (5.0 on AMD64)
File version: 10.0.1.0

Private build:
Special build:

Copyright (c) 1996-2009 SuperSpeed LLC. All Rights Reserved.
This product may be covered by one or more of the following
patents: 5,577,226, 5,606,681, 5,918,244, 6,370,615, 6,629,201,
6,651,136, 7,017,013, 7,039,767, 7,111,129, 7,475,186, and
other patents pending.
[/more]

ну и ещё вкусовщина - enterprise выглядит очень круто и мудрёно и обещает некоторые интересные вещи, в частности автоматический ресайз диска, но при этом частенько приходится перезагружаться. Plus попроще, но по крайней мере все заявленные вещи в нём работают. хотя когда нужно свободное озу - приходится вручную удалять диск, а позже создавать заново
Автор: muzf
Дата сообщения: 26.03.2013 21:06
Shuld
Именно его и исползовал, хотя тестов никаких про них не читал
Обещанные ресайз на лету в qSoft не работает кстати.
Автор: Bulat_Ziganshin
Дата сообщения: 26.03.2013 21:14
muzf
по моим наблюдениям ресайз работает - если на диске есть свободное место и другая программа просит озу, то она его может получить. а может и не получить судя по увеличению объёма своп-файла, он позволяет отсвопить неиспользуемую часть диска. но в целом всё странно и толком не документировано. что очень похоже на fa кстати
Автор: muzf
Дата сообщения: 26.03.2013 23:03
Места много, но даже ресайз на пару десятков Мб, при пустом диске, требует перезагрузки, очень неудобно. Заявленная функция, только из-за которой его и ставил, по сути у меня не работает.
Автор: Bulat_Ziganshin
Дата сообщения: 26.03.2013 23:43
muzf
в том-то и дело, что вручную ресайз делать не надо. ручной как раз отлично работает в Plus
Автор: Shuld
Дата сообщения: 26.06.2013 18:53
Тест архиватора WinRAR 5.00 бета 5 на июнь 2013 года

Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ

Провел 2 теста, результаты для очень большого коэффициента сжатия опубликованы здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=32358&start=1960#4
Результаты для небольшого коэффициента сжатия ниже:
Размер данных 537 864 577 байта, 471 файл, 47 папки.

WinRAR 4.20
Скоростной, непрерывн., 20 с, 391 252 466
Быстрый, непрерывный, 52 с, 367 136 195
Обычный, непрерывный, 1м 03с, 366 764 844
Хороший, непрерывный, 1м 03с, 366 698 009
Максимальный, непрер., 1м 00с, 366 675 343

WinRAR 5.00 бета 5, формат RAR
Скоростной, непрерывн., 20 с, 391 227 855
Быстрый, непрерывный, 48 с, 367 113 866
Обычный, непрерывный, 1м 03с, 366 742 442
Хороший, непрерывный, 1м 04с, 366 675 353
Максимальный, непрер., 1м 06с, 366 652 648

Видно, что новая версия в режиме совместимости со старым форматом сжимает чуть лучше предыдущей версии 4.20. Но разница непринципиальная.

WinRAR 5.00 бета 5, формат RAR5, скоростной, непрерывный
разный размер словаря
4 МБ, 23 с, 385 434 201
8 МБ, 24 с, 385 373 496
16 МБ, 24 с, 385 337 385
32 МБ, 24 с, 385 303 754
64 МБ, 24 с, 385 292 718
128 МБ, 29 с, 385 285 044
256 МБ, 29 с, 385 285 610
Никакого особенного преимущества большие размеры словаря для метода Скоростной не дают. Скорее наоборот, только увеличивают время архивирования.

WinRAR 5.00 бета 5, формат RAR5, словарь 256 МБ (максимальный для моего ПК)
Скоростной, непрерывный, 29 с, 385 285 610
Быстрый, непрерывный, 1м 53с, 310 288 565
Обычный, непрерывный, 1м 59с, 309 938 323
Хороший, непрерывный, 2м 04с, 309 878 989
Максимальный, непрер., 2м 07с, 309 857 391

Метод Скоростной стоит особняком, а остальные методы в формате RAR5 образуют очень плотную группу по времени сжатия, еще более плотную, чем в старом формате RAR. Что не есть хорошо.

WinRAR 5.00 бета 5, формат RAR5, максимальный, непрерывный
разный размер словаря
4 МБ, 1м 05с, 366 572 644
8 МБ, 1м 20с, 347 810 343
16 МБ, 1м 21с, 333 090 201
32 МБ, 1м 20с, 315 035 742
64 МБ, 1м 24с, 313 761 318
128 МБ, 2м 02с, 312 714 422
256 МБ, 2м 07с, 309 857 391

В данном тесте (как и в предыдущем) в новом формате RAR5 размер словаря оказывает влияние больше, чем выбор метода в группе Быстрый - Максимальный.
По умолчанию стоит 32 МБ, что достаточно хороший выбор!
------
7zip 9.30 альфа, метод LZMA2, ультра, словарь 48 МБ
2 м 09 с, 318 518 806 байта.

Эти же данные архиватором FreeArc 0.67 v2012-12-12
на методе m87 я сжимаю за 44 с, 308 662 644 байт
Скачать arc.ini в виде архива arc2013-06-05.zip можно здесь:
http://yadi.sk/d/gytcnNw85PaCA

Дополнение от 29.06.2013
Как "включить" методы -m8... описано здесь
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=780#19
Автор: Shuld
Дата сообщения: 30.06.2013 11:21
Тест архиватора WinRAR 5.00 бета 6 на июнь 2013

Процессор E6750 (2.66GHz, 2 ядерный), WinXP SP3, 32-разрядная, ОЗУ 2 ГБ
Размер данных 1 905 280 246 байта, 3 063 файлов, 576 папки. В основном – документы Word 2003.

WinRAR 4.20
Скоростной, непрерывн., 5м 59с/3м 00с, 810 255 784
Быстрый, непрерывный, 4м 48с/7м 30с, 720 359 173
Обычный, непрерывный, 7м 16с/5м 29с, 713 967 340
Хороший, непрерывный, 8м 37с/5м 40с, 713 618 391
Максимальный, непрер., 6м 27с/5м 18с, 713 507 342
Сначала все методы сжатия прогонялись по 1 разу, затем для уточнения времени сжатия – по второму разу. Очень большой разброс по времени.
Как ни смешно, мне показалось, что минимальное время получается после чистки корзины. Поэтому во всех последующих тестах я после удаления архива в корзину, в обязательном порядке чистил корзину. И только после этого прогонял следующий тест.

WinRAR 5.00 бета 6, формат RAR
Скоростной, непрерывн., 3м 20с, 810 197 927
Быстрый, непрерывный, 4м 37с, 720 305 138
Обычный, непрерывный, 5м 23с, 713 907 612
Хороший, непрерывный, 5м 25с, 713 559 020
Максимальный, непрер., 5м 44с, 713 447 423

WinRAR 5.00 бета 6, формат RAR5, скоростной, непрерывный
разный размер словаря
4 МБ, 3м 30с, 797 838 222
8 МБ, 3м 29с, 793 645 929
16 МБ, 3м 52с, 790 269 607
32 МБ, 4м 45с, 790 228 006
64 МБ, 5м 01с, 790 225 916
128 МБ, 5м 13с, 790 219 184
256 МБ, нет в меню выбора.
Для ОЗУ 2 ГБ в меню исчез размер словаря 256 МБ.
Большой размер словаря, свыше 32 МБ, для метода Скоростной практически не увеличивает сжатие, а только увеличивает время архивирования. При этом метод Скоростной становится медленнее и хуже по сжатию, чем метод Быстрый в формате RAR. Т.е. метод Скоростной имеет смысл только для размеров словаря 8 - 16 МБ.

WinRAR 5.00 бета 5, формат RAR5, быстрый, непрерывный
разный размер словаря
4 МБ, 5м 46с, 718 825 147
8 МБ, 5м 55с, 620 909 002
16 МБ, 6м 07с, 568 083 683
32 МБ, 6м 26с, 533 068 300
64 МБ, 7м 13с, 520 709 042
128 МБ, 10м 20с, 513 941 959
256 МБ, не поддерживается для ОЗУ 2 ГБ.
Для метода Быстрый увеличение размера словаря до максимального значительно увеличивает степень сжатия. Время архивирования увеличивается менее чем в 2 раза.

WinRAR 5.00 бета 6, формат RAR5, обычный, непрерывный
разный размер словаря
4 МБ, 5м 36с, 716 449 345
8 МБ, 6м 00с, 618 805 411
16 МБ, 6м 01с, 566 329 616
32 МБ, 6м 09с, 531 520 530
64 МБ, 6м 34с, 519 212 357
128 МБ, 10м 17с, 512 448 041
256 МБ, не поддерживается для ОЗУ 2 ГБ.
На десятые доли процента сжатие лучше, чем у метода Быстрый.
По результатам теста метод Обычный выглядит быстрее метода Быстрый. Я так не думаю. Однако, если разница так мала, что влияние различных случайностей больше, то есть ли смысл в использовании метода Быстрый?

WinRAR 5.00 бета 6, формат RAR5, хороший, непрерывный
разный размер словаря
4 МБ, 5м 51с, 716 102 702
8 МБ, 6м 51с, 618 467 045
16 МБ, 6м 48с, 566 047 126
32 МБ, 7м 11с, 531 269 506
64 МБ, 7м 53с, 518 963 295
128 МБ, 11м 19с, 512 211 439
256 МБ, не поддерживается для ОЗУ 2 ГБ.
Метод Хороший очень мало отличается от Обычного.

WinRAR 5.00 бета 6, формат RAR5, максимальный, непрерывный
разный размер словаря
4 МБ, 6м 36с, 715 982 994
8 МБ, 7м 20с, 618 356 069
16 МБ, 7м 04с, 565 954 097
32 МБ, 7м 16с, 531 182 048
64 МБ, 8м 00с, 518 877 718
128 МБ, 12м 05с, 512 131 072
256 МБ, не поддерживается для ОЗУ 2 ГБ.
Метод Максимальный медленнее метода Обычный примерно на 20%, степень сжатия лучше на сотые доли процента.

7zip 9.20, метод LZMA2, ультра, словарь 64 МБ, 12 м 44 с, 503 801 650 байта.
FreeArc 0.67 v2012-12-12, метод m87, 5 м 41 с, 499 743 789 байт.

---------------
Рекомендации по выбору методов и параметров архивирования архиватора WinRAR 5.00 бета 6

Замечание: рекомендации относятся не к сжатию одиночных файлов, а к сжатию больших размеров информации, сотни мегабайт и больше.
Для эффективного сжатия в таких случаях всегда надо включать параметр «создать непрерывный архив»! (Можно, конечно, и не включать, но тогда сжатие будет не самым сильным).

Для быстрых компьютеров выбирать метод Обычный и максимальный доступный размер словаря. Большой размер словаря время архивирования увеличивает не очень сильно.
Метод Максимальный дольше на 10 %, но увеличивает сжатие лишь на сотые доли процента – это для экстремалов.

Для медленных компьютеров выбирать метод Быстрый (не путать со Скоростным).
Он на 10 % быстрее метода Обычного, а сжатие хуже только на доли процента.
Еще быстрее компьютер будет работать при уменьшении размера словаря. Можно уменьшить, например, до 64 Мб. Но тут тоже нужно знать меру. Сильно уменьшать размер словаря бессмысленно.

Метод Скоростной, хоть и быстрее Быстрого, но сжатие намного хуже. Использовать большого смысла не вижу. Но если использовать, то для того, для чего он и предназначен – именно для скоростного сжатия с размером словаря 8 - 16 МБ.

Еще быстрее работает метод Скоростной старого формата RAR.

Эти рекомендации в виде таблички

Страницы: 12345678910111213141516171819202122232425262728293031

Предыдущая тема: canopus pro coder


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.