Последняя доступная версия:

http://www.overclockers.ru/softnews/33991.shtml

ему нужно около 700Мб(по показаниям таскменеджера) для этой операции, поэтому действительно 1Гб физической памяти это уже напряг.

.rain писал(а):

Во-первых, не у всех в распоряжении есть 512 и выше Мб оперативной памяти

Приведу пример: я на своей профильной машине в Crysis играть не буду. Угадайте почему?

.rain писал(а):

, во-вторых, такое потребление памяти только одним архиватором не есть хорошо...

Архивирование процесс специфический, не думаю что вы сжимая хГб информации захотите поиграться(к примеру) во что-то. А архивируя несчастные 100Кб текста совершенно не важно сколько использовалось памяти за этот мгновенный процесс. Вот если бы столько памяти поедал какой-нибудь почтовик(постоянно висящий в памяти), то это да - повод забеспокоиться.
Да, можно сделать малопотребляющую программу, но она превратиться ... в WinRar к примеру . Высокие степени сжатия(или скорость) тоже просто так не даются.

Мне не интересно знать на чем ты будешь или не будешь играться в Crysis


Во время сжатия указанных хГб информации на моей машине может выполняться еще несколько тяжелых приложений. Благодаря отличным системным планировщикам я могу не обращать внимания на полную загрузку процессора, а вот при малом количестве памяти излишняя прожорливость одного из процессов будет уже заметна.
Для почтовика (или какого-либо другого сервера) стабильное использование большого объема памяти вполне нормально. Все зависит от того, как ты его настроишь.
Речь, собственно, о неправильном выделении памяти для процесса. Он берет не процент от общего размера памяти (например, треть), а объем вне зависимости от того, сколько информации сжимается. На упаковку 10-тимегабайтного файла отдается 100-150 Мб памяти - куда такое?
В общем-то, это первый упаковщик, который накладывает ограничение (причем, ощутимое) на используемое железо. Что, естественно, никак не уменьшает его преимуществ на SMP-машинах с большим объемом памяти

Если реализация алгоритма хромает - ему нужно много памяти, по сравнению с вариантом, где реализация сделана лучше

Насчет настроек игр, в общем-то правильно, подобный шаг помогает и здесь... Просто отслеживание потребления памяти можно было бы сделать получше, а не загонять систему в своп. (Хотя насчет игр не всегда справедливо - некоторые сделаны настолько паршиво, что меняй-не меняй настройки - не поможет).

Насчет памяти не согласен, не стоит писать программы, потребляющие много ресурсов только из-за того, что память относительно дешевая.

Неудобство интерфейса: нет интеграции в ТК (7.0).
Неудобство алгоритма: сжатие большого количества файлов (у меня 700к) на гигабайте памяти (офисный целерон) вылетает с обычными настройками памяти (ультра->700Мб).
Причина

armadillo в ТК6.х вроде проблем нет больших(архивы читаются и пакуются с некоторыми но..). А насчёт 700к файлов это задачка не повседневная для простого юзера. Только на архивирование в режиме ультра идёт 700Мб памяти + на создание списка файлов перед копированием, вот и получается перебор(на 65к(больше не насобирал) файлов идёт около 750Мб).

От бесплатного софта добра не жди. 7-Зип скорее хорош, чем... Убивает такое недоразумение, что нельзя напрямую файлы вытаскивать (drug'n'drop) из открытого архива и невозможность создания архивов WinRAR.

Можно, проверил - работает. Кстати эта функция отвратно реализована что в winrar что в 7-zip'е(сначала идёт распаковка во временную папку, а потом перенос до места назначения).
А насчёт создания архивов WinRar: он и не должен создавать, это очевидно(WinRar создаёт архивы 7-zip?! ).

mein то что я писал актуально для 7.42. только что скачал 7.57, он драг эн дропом таки обзавелся. а вот насчет темп папки буду знать...

поскольку рар читает 7зип, остается только объяснить этот факт получателям архива.

достоинство 7зип - несмотря на очень долгую архивацию, распаковка бывает быстрее рара.

собственно есть две тяжелые задачи:
1) ежедневные архивы проекта.
я тупо архивирую папку после каждого пакета изменений, в среднем получается раз в день или чаще. один архив - 1200 файлов, 15мб, сжатый 8мб (там картинки). 500 архивов - 4гб.
Совпадения между соседними архивами - 99.9%.
написал скрипт, распаковывающий все архивы в папку с соответствующим именем и удаляющий лишние файлы, чтобы потом сжать все оптом. с настройками ультра-64мб не вышло (1гиг оперативки), с 32мб все сжалось в 34мб.
с этим проблема решена.

2) ежедневные дампы базы. совпадения между соседними дампами тоже очень большие.
у меня есть два вида дампов - малый (~50мб) и большой - 170мб.
малый с настройками 32мб сжимается примерно с соотношением 500мб->33.
с настройками 64мб те же файлы сжались в 4.4мб.
Итого 230 файлов (7.6гига) ужались в 15мб.
оставить на ночь пережать архив раз в две недели не проблема.
с большим дампом намного хуже.
разница между архивами единичных файлов и общим ничтожна, и то и то сжимаются примерно в 10 раз.
хочется такого же как с малым, и беспокоит что с малым может произойти та же фигня, т.к. причина скорее всего в объеме буфера. (хотя спорил с народом, который считает, что там еще какие-то настройки включаются).
Думаю разбивать дампы на несколько по таблицам.

Можно ли сделать так, чтобы после распаковки SFX-архива, выполнялся запуск исполняемого файла?(не создавая SFX-архив из командной строки)

Вопрос: у меня Core2Quad Q6600, почему архивировать можно только в 2 потока? В тестировании производительности можно аж в 8 потоков???

Для наибольшего сжатия какие параметры и как нужно поменять? Размер словаря, размер слова, размер блока..

в 99% случаев все побольше. Иногда (нечасто) чуть лучше алгоритм PPMD, но смотри где придется распаковывать.

Очевидно, что на тест программа запускает несколько независимых потоков сжатия. Чтобы проилюстрировать это запустите одновременно(без фанатизма ) архивироваться несколько файлов/папок в отдельные архивы, тогда и 4(и 8-ми "ядерник") будет загружен на полную. Проблема в том, что это будут разные архивы... Видимо алгоритмы архивирования плохо приспособлены для распараллеливания на потоки, т.к. даже два ядра не используются "во всю".

"интерфейс" файлового менеджера с постоянным дерганьем обновления и был не сахар, но на этот раз я попытался распаковать архив из папки, в которую идет закачка.
Это превратилось в "увлекательную игру" - успею ли я промотать и выделить нужный файл до очередного дергания и СБРОСА прокрутки.
ппц.

Скачал игру из 13 архивов rar , как их обьединить в один с помощью 7 Zip или хотябы WinRAR ???

ВЕКТОР Распаковать и запаковать заново(уже без разбиения на архивы).

а чё вам не нравится? у мя 8гиг оперы всё работает на ура ну если у вас машинка слабая, чёж вы гоняетесь за лишними 10%-20% сжатия?
Добавлено спустя 2 минуты, 21 секунду
а ещё у 7зипа есть очень мощная фишка при работе с нтфс сжатием.

у меня процессор intel Q6600 и операционка Win2003 x64 sp2 скачиваю отсюда http://www.overclockers.ru/softnews/30130.shtml
7-Zip 4.60 Beta (1.9 MB, Windows XP/2003 x64 для Intel, MSI инсталлятор, open source)
файл 7z460-ia64.msi и при запуске мне пишет - "Данный пакет установки не поддерживается этим типом процессора. Обратитесь к поставщику продукта."
я иногда настырный и скачал 7-Zip 4.60 Beta (1.5 MB, Windows XP/2003 x64 для AMD, MSI-инсталлятор, open source).
и о чудо... установка прошла нормально и более того архиватор нормально работает
1. почему у меня не установился архиватор предназначенный для моего процессора?
2. чем мне грозит использование архиватора предназначенного не для моего процессора?


у меня при архивации на Win2003 x64 задействуются все 4 ядра одинаково