Помощь - Поиск - Пользователи - Календарь
Полная версия: Как ускорить Фотошоп? Скретч, своп и т.п.
ProDTP > Графика и препресс > Adobe Photoshop
Matv!ck
Целый день лазил в поисках инфы по этой теме. Прочитал много всего интересного. Но кое-что осталось неясным. Помогите, пожалуйста, прояснить следующие вопросы:


1. У меня 2 жестких диска. SATA2 750gb и IDE 75gb. Скретч Шопа лежит на IDE, что лучше: разбить SATA2 и слить скретч на логический раздел, или оставить его на IDE?

2. Стоит ли раскидывать скретч по нескольким физическим/логическим дискам?

3. Куда лучше ставить Шоп: на диск со скретчем, или на системный?

4. Можно ли помимо скретча Шопа устанавливать на тот же диск скретч иллюстратора 3Д макса и т.п.?

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

6. У меня 4 гига оперативки, Винда(32 бит) видит 3,5 гига. Сколько процентов нужно отвести Шопу? Я где-то читал, что можно в Винде прописать какую-то строку, и ФШ заюзает все 4 гига. Подскажите, плиз, как и где это пишется?

7. Говорят, чтобы ФШ работал быстрее, нужно делать дефрагментацию винта со свопом примерно раз в 2 недели. Еще некоторые говорят, что при дефрагментации винты сильно нагреваются и мрут. Поделитесь опытом дефрагментации. В самом деле ее нужно делать так часто? Есть ли при этоб риск убить жестак?

8. Пытаюсь увеличить своп Винды. Она мне рекомендует 5373мб, но когда я задаю значения, возмущается, что больше 4096мб. Как с этим быть?
feuerloescher
1. На оба

Цитата(Matv!ck @ Jun 24 2009, 20:50) *
6. <...> и ФШ заюзает все 4 гига.

Забудьте, не "заюзает".

8. Оставить своп в покое.
PAIN.(t)
1. В общем-то пофигу. Главное чтобы:
    — это не был системный раздел
    — на этом же разделе не находился своп-файл (pagefile.sys)

2. Зачем? Принцип работы скретча таков: когда приложению не хватает оперативки, оно начинает записывать данные на Primary Scratch, не хватает Primary – начинает писать на Secondary… ну и т.д.
Вывод – лучше одному скрэтч-диску выделить достаточно места, дабы на все хватило.

3. См. п.5.

4. Да, можно. Выделять каждому приложению отдельный скретч – разделов не напасешься. Просто нужно быть готовым к тому, что при одновременной работе приложения могут подтормаживать. Или работать в них изолировано.

5. Если хорошо знакомы с понятием "переменные среды" и справитесь с ними; а также если не пугаетесь, что у вас в системе будет 10 логических дисков smile.gif, то желательно.
И более развернуто по пункту 3: в идеальном сферическом иридиево-палладиевом мире было бы неплохо разнести собственно ОС, своп-файл ОС, Program Files и их хвосты на отдельные физические диски, да еще и в начальные сектора…
В реальности же все намного сложнее: столько физических дисков нет; чем дальше раздел от начальных секторов диска – тем ниже скорость чтения-записи (смысл в таком скретче?); даже если все почти идеально и есть 4 физических девайса – персловутые 10 разделов в Проводнике глаза все-таки мозолят…
Баланс между желаемым и действительным попытайтесь найти сами smile.gif

6. AFAIK, 32-битная система может увидеть сколько угодно (при верном алгоритме подсчета), но пережевать сможет 3 с копеечками гига, 32-битное приложение – 2 с копеечками…
Отсюда имеем: сколько процентов? Больше 2 гиг не стоит – Шоп их видит, да не съест, бо 32-битный…
Memory remap feature в биосе и ключи загрузки в boot.ini – палка о двух концах. Траблы были описаны и здесь на форуме, найду эти топики – выложу ссылки.

7. Не вижу никакой связи между Шопом, свопом и дефрагментацией. Своп-файл не нужен уже в конце сеанса работы, т.к. несет в себе только то, что не поместилоь в RAM-e. Причем в таком формате, что хрен его оттуда выковыряешь… Куча твикеров позволяют при выключении компьтера тупо потереть его. А если это делают твикеры – значит где-то это просто прописывается в реестре smile.gif
А вот дефрагментацию делать нужно, да. Регулярно ли? ХЗ… скорее, по показаниям…

8. Со свопом ситуация следующая: считает Винда одно, а дать может совсем другое… больше 4096 (=4х1024=4 Гб) 32-битка сделать не даст smile.gif
А еще некоторые люди говорят, что при 3-4 Гб оперативки своп не нужен вообще wink.gif
lossless
В 64 битной винде фотошоп видит использует куда больше 2 гб smile.gif
вот можно почитать
Вкратце - 8 гб на макоси и 6 гб на винде х64 Не напрямую к сожалению но как scratch (кэш для данных) Там же кстати боольшая темка про ускорение шопа.
PAIN.(t)
loxless
Вы типа котика, территорию метите? Отметиться в каждой теме, типа, без понятия о ее сути?

1. Разговор о 32-битах. Вопрос о 64-х даже не стоял. Америку вы, сударь, не открыли: любой, кто имеет представление об адресуемом пространстве памяти и сам это знает (или имеет какое-нить представление о порядке этого пространства).

2. "Вот можно почитать"
Читайте сами. По следующим причинам:
— виртуализация стара, как мир;
— адреса ОЗУ выше 32-битного лимита ОС держит одна-единственная софтюлина: Superspeed RamDisk Plus, и упаси Господи спутать ее с российским RAM Disk;
— софтюлинка стоит денег, причем приличных (50 у.е. за 32-битную версию и 100 у.е. за 64-битную);
— без танцев с бубном она не заводится;
— еще никто толком не выдал анализ производительности системы с таким виртуал-драйвом и без него.

3. 8 гб на макоси и 6 гб на винде х64
Хорошо так написано, аж слеза потекла… Cocoa vs Carbon vs 64-bit – для полного понимания процесса… А с Виндовозом и так все ясно…

4. А по последней ссылке че интересного-то? Толпа народу пиписьками меряется, а в перерывах друг другу азбуку рассказывают…

ВОПРОС: Нахрен был нужен такой пост??? Типа, засвидетельствовать, что "я тож об этом слышал"?
lossless
В сущности человек спрашивал как ускорить шоп. Последняя тема (пиписьки) как раз и содержит анализ способов "ускорения" причем на конкретных тестах. Ну если все прочитать. Т.е. народ извращался со скратчами и прочей байдой и проверял как это отражается на быстрдействии. И бывало что никак smile.gif Вплоть до замедления. Очень прочищает мозги.
Matv!ck
Спасибо всем за ответы. Отдельное спасибо PAIN.(t).
langry
…вставлю пять копеек по дефрагментации. Не претендуя на истину — не очень рекомендуют часто дефрагментировать NTFS: толку — чуть, а износ диска здорово возрастает.

PAIN.(t), а насчёт муравьёв в печени отдельных разделов под систему, %Program Files% и %Docs% — это ты правильно подметил. Одно „но“(конкретно для Винды): даже при вынесенных в отдельный раздел Program Files, каждая установка всё-же мусорит на командный диск. Не *nix'ы они в этом отношении, увы. Весело бывает после хвосты чистить.
Rod_of_Sky
свой пятак вставлю:
стараюсь всё, что можно разделить - разделять
у меня 3 физ.диска общим объёмом около 1.5 ТБ
разбито на 8 логик. 2 оси (х32 и х64)
системы, програмфайлы и свопы на разных, по возможности.
програмфайлы х32 в х32 и програмфайлы х32 в х64 ставлю одни поверх других - за одно и настройки одинаковые.
все свопы на отдельные логики (и, по возможности физики).
у програм конечно всё в одной куче, иногда только шопу отдельно выдаю, если большая работа.

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

может кто и посчитает извращением, но оказалось довольно удобно.
steve
вроде уже много ответов дали, но автор не указал самого главного. для чего это всё делается. если открывать мелкие файлы, то это ускорение особо не понадобится. если же открывать огромные файлы, то тут всё будет упираться в производительность винтов, шины и т.д.

была еще такая "железяка" как Gigabyte's i-RAM storage devicе. PCI-карта с 4 слотами под планки памяти, получался очень скоростной винт, но были и свои минусы (цена, лимит 4гб и прочее). вроде, обещали выпустить новую версию более 4гб, но кажется всё так и осталось.
lossless
Полезно все же прогнать тестик (ага, тот самый) до "ускорения" и после. А лучше на каждом этапе "оптимизации". Не тот случай когда "вера творит чудеса" smile.gif Я к примеру плюнул на "оптимизацию" где-то после 10-й переустановки системы.
MkOFF
Почему никто не сказал человеку про Cache Level?
При наведении мышой - внизу появляется его описание. Тож полезно..
Edit-Preference-Perfomance
History & Cache
Это текстовая версия — только основной контент. Для просмотра полной версии этой страницы, пожалуйста, нажмите сюда.
Русская версия Invision Power Board © 2001-2012 Invision Power Services, Inc.

Реклама

   Rambler's Top100    Яндекс цитирования