Login
ускорить работу компайлера
NEW 21.03.13 20:13
Zuletzt geändert 21.03.13 20:56 (anly)
я не уверен что тема относится более к форуму "Программировамие", чем к " Компьютер & Co". Однако я тему открыл только потому что именно программированием занимаюсь. (если модераторы не согласны, не возражаю, если перенесёте)
С полгода назад на работе получил новый комп с Вин7 и 8 core процессором: по сравнению с предыдущим ХР (не помню сколько core) стал летать...
Тогда я предусмотрительно замерил время полной компиляции проэкта - около 6 минут (старый комп раза в четыре дольше молотил).
Сейчас - в два раза больше (около 12 мин.)
Диски для Виндовса и для проэкта раздельные (логически. физически - один), каждый гдето 120 ГБ. Обое наполовину пустые.
Хотя занятый объем дисков (т.е. что занято файлами) конечно за пол года тоже увеличелся наверно раза в два.
Я уже пробовал бороться с тормозами: отключал разные службы - суперфетч, свопфайл вообще отключил, шифрование отключил, сжатие отключил, индексацию отключил. Но ощутимый результатов нет.
Также пробовал разные дефрагментаторы.
Вопросы такие:
1) стоит ли дефрагментировать диск проэкта, на котором каждой компиляцией создаётся/модифицируется куча файлов (напр. obj)
это может улучшить производительность если коприлирую я каждый день и не мало раз? (честно я не заметил улучшения, почти)
2)windows Leistungsinformationen показывает что полгода назад что сейчас одно и тоже:
Процессор - 7.6
Графика - 6.4
Память - 5.9
Диск - 5.9
Вот думаю если отключить сжатие это теоритически повысить или понизит производительность? ведь работа диска относительно медленная (без сжатия больше писать), а процессор относительно быстрый (т.е. быстро сжимает).
Хотя я пробовал - особой разницы не заметил. Но теоретически всё же интересно...
Главный вопрос: откуда взялись тормоза?
С полгода назад на работе получил новый комп с Вин7 и 8 core процессором: по сравнению с предыдущим ХР (не помню сколько core) стал летать...
Тогда я предусмотрительно замерил время полной компиляции проэкта - около 6 минут (старый комп раза в четыре дольше молотил).
Сейчас - в два раза больше (около 12 мин.)
Диски для Виндовса и для проэкта раздельные (логически. физически - один), каждый гдето 120 ГБ. Обое наполовину пустые.
Хотя занятый объем дисков (т.е. что занято файлами) конечно за пол года тоже увеличелся наверно раза в два.
Я уже пробовал бороться с тормозами: отключал разные службы - суперфетч, свопфайл вообще отключил, шифрование отключил, сжатие отключил, индексацию отключил. Но ощутимый результатов нет.
Также пробовал разные дефрагментаторы.
Вопросы такие:
1) стоит ли дефрагментировать диск проэкта, на котором каждой компиляцией создаётся/модифицируется куча файлов (напр. obj)
это может улучшить производительность если коприлирую я каждый день и не мало раз? (честно я не заметил улучшения, почти)
2)windows Leistungsinformationen показывает что полгода назад что сейчас одно и тоже:
Процессор - 7.6
Графика - 6.4
Память - 5.9
Диск - 5.9
Вот думаю если отключить сжатие это теоритически повысить или понизит производительность? ведь работа диска относительно медленная (без сжатия больше писать), а процессор относительно быстрый (т.е. быстро сжимает).
Хотя я пробовал - особой разницы не заметил. Но теоретически всё же интересно...
Главный вопрос: откуда взялись тормоза?
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 20:45
in Antwort anly 21.03.13 20:13
Винда 64 или 32 бита?
Для 64 бит на СИ сервере мы получили значительное увеличение скорость компиляции только увеличив память до 8 гигов.
Попробуйте еще удалить все файлы из мусорной корзины. Когда там собирается солидное количество файлов могут быть придичные тормоза.
Компайлер то какой и что за язык?
Для 64 бит на СИ сервере мы получили значительное увеличение скорость компиляции только увеличив память до 8 гигов.
Попробуйте еще удалить все файлы из мусорной корзины. Когда там собирается солидное количество файлов могут быть придичные тормоза.
Компайлер то какой и что за язык?
NEW 21.03.13 20:50
in Antwort AlexNek 21.03.13 20:45
винда 64бит.
память 4гб.
мусор удаляю регулярно. ccleaner тоже запускаю.
Программирую только на VisualStidio2008.
Реже на VisualStudio2010- кстати работает ощутимо медленнее. Следующие версии проэкта будут на VS2010 так что надо чегото решать...
память 4гб.
мусор удаляю регулярно. ccleaner тоже запускаю.
Программирую только на VisualStidio2008.
Реже на VisualStudio2010- кстати работает ощутимо медленнее. Следующие версии проэкта будут на VS2010 так что надо чегото решать...
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:02
in Antwort anly 21.03.13 20:13
Судя по ссылкам он обьектные файлы - пишешь Плюсах.
В плюсах, насколько помню, есть фишка с включаемыми файлами - добавляется чуток - время растет экспоненциально.
Борланд в свое время делал предкомпиляцию заголовочных файлов. Есть ли такое в ВС - не знаю - рой настройки.
Если нету, то можно экономить на компиляции путем включения цпп-файлов как и заголовочных... морока, но раза в три
ускорить получалось...
Так, надо сбегать недалеко - допишу потом...
В плюсах, насколько помню, есть фишка с включаемыми файлами - добавляется чуток - время растет экспоненциально.
Борланд в свое время делал предкомпиляцию заголовочных файлов. Есть ли такое в ВС - не знаю - рой настройки.
Если нету, то можно экономить на компиляции путем включения цпп-файлов как и заголовочных... морока, но раза в три
ускорить получалось...
Так, надо сбегать недалеко - допишу потом...
NEW 21.03.13 21:16
in Antwort Murr 21.03.13 21:02, Zuletzt geändert 21.03.13 21:32 (anly)
точно - в плюсах.
шарп (пользуюсь только дома, а на работе только для тестов) гораздо проворнее (впрочем больших проэктов на шарпе я не пробовал).
некоторые проэкты солюшена у нас используют boost. Так вот они компилируются ощутимо дольше.
Сам я не люблю boost. Как минимум там где используется у нас. Это похоже как на танке в булочную съездить что за углом, вместо велосипеда. Неоправданная сложность, где можно сделать просто. В callstack дебагера смотреть страшно: десяток вызовов вместо одного (если бы без boost).
Кстати boost - это тоже новое что появилось в нашем солюшене за пол года..
шарп (пользуюсь только дома, а на работе только для тестов) гораздо проворнее (впрочем больших проэктов на шарпе я не пробовал).
некоторые проэкты солюшена у нас используют boost. Так вот они компилируются ощутимо дольше.
Сам я не люблю boost. Как минимум там где используется у нас. Это похоже как на танке в булочную съездить что за углом, вместо велосипеда. Неоправданная сложность, где можно сделать просто. В callstack дебагера смотреть страшно: десяток вызовов вместо одного (если бы без boost).
Кстати boost - это тоже новое что появилось в нашем солюшене за пол года..
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:31
in Antwort anly 21.03.13 20:50
NEW 21.03.13 21:32
in Antwort anly 21.03.13 21:16
А как вас решена "проблема" с предкомпилированными заголовками?
NEW 21.03.13 21:35
in Antwort AlexNek 21.03.13 21:31
надо будет спросить о еще 4 гб...
Глядя на таскмэнэджер память расходуется под потолок. Иногда даже Виндовс предлагает чего нибудь закрыть, ввиду малости остатка свободной памяти.
Глядя на таскмэнэджер память расходуется под потолок. Иногда даже Виндовс предлагает чего нибудь закрыть, ввиду малости остатка свободной памяти.
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:38
in Antwort anly 21.03.13 20:50
Странные вы вещи пишете
При 4 гигах Виндус должна сама загрузить их в эти 4 гига и к диску уже не обращаться.
При 4 гигах Виндус должна сама загрузить их в эти 4 гига и к диску уже не обращаться.
"Was mich nicht umbringt, macht mich stärker."
NEW 21.03.13 21:39
in Antwort AlexNek 21.03.13 21:32
решена просто: сразу после stdafx.h стоить #pragma hdrstop.
После которого обычно еще куча инклудов.
Весь проэкт уже 20 лет как живёт, а порядок в нём похоже только я и навожу, беря на себя ответсвенность и риск.
boost включен в предкомпилированный заголовок, но видно он слишком большой.
После которого обычно еще куча инклудов.
Весь проэкт уже 20 лет как живёт, а порядок в нём похоже только я и навожу, беря на себя ответсвенность и риск.
boost включен в предкомпилированный заголовок, но видно он слишком большой.
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:40
in Antwort Alex_MUC 21.03.13 21:38
Это чисто теоретически рассуждения или есть документ от микрософта?
NEW 21.03.13 21:43
in Antwort anly 21.03.13 21:35
Это я бы сделал в первую очередь,тем более что память сейчас не такая уж и дорогая.
Второе, отмониторь нетворк. У нас сделали ссылку на сетевой диск для данных пользователя и студия любит этим пользоваться.
Второе, отмониторь нетворк. У нас сделали ссылку на сетевой диск для данных пользователя и студия любит этим пользоваться.
NEW 21.03.13 21:44
Проэкт после успешной компиляции на диске занимает около 10 гб ( это включая исходники и obj и прочее)
на диске обычно имеется штук 5 версий проэкта (кроме других редко используемых проэктов). которые переодически удаляются, и заново грузятся/билдятся с соурсконтрола.
in Antwort Alex_MUC 21.03.13 21:38, Zuletzt geändert 21.03.13 22:17 (anly)
В ответ на:
загрузить их в эти
пардон, не понял: "их" - это что? загрузить их в эти
Проэкт после успешной компиляции на диске занимает около 10 гб ( это включая исходники и obj и прочее)
на диске обычно имеется штук 5 версий проэкта (кроме других редко используемых проэктов). которые переодически удаляются, и заново грузятся/билдятся с соурсконтрола.
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:46
in Antwort AlexNek 21.03.13 21:43
В ответ на:
отмониторь нетворк
можно поподробнее? в сетях я не силён...отмониторь нетворк
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 22:00
in Antwort Murr 21.03.13 21:02
Часть вторая.
Хоть и не должно влиять, но мусор надо чистить. Чистить надо не только корзину, но и все временные файлы.
Где-то тут есть папочка с временными файлами: C:\Windows\Microsoft.NET\Framework\*
Часть тртья.
Проверить подмапленные, отсутствующие и субституционные диски. Все, которые не используются, а не используются почти всегда все - похерить.
Проверить сколько и чего прописано в патх. Почистить. Вплоть до того, что создать юзера только под разработку.
Часть четвертая.
посмотреть, куда пишутся обьектники и куда сбрасываются готовые либу и ехешники. По идее - обьектники должны писаться не на тотже физический диск где исходники и куда пойдут готовости.
Во времена когда винчестера на ПК были в диковикнку, Я пользовал такую штуку как RAM(virtual)-диск для обьетных и других файлов временного хранения - порядка на 3-4 по производительности. Как сейчас - не тестил.
Хоть и не должно влиять, но мусор надо чистить. Чистить надо не только корзину, но и все временные файлы.
Где-то тут есть папочка с временными файлами: C:\Windows\Microsoft.NET\Framework\*
Часть тртья.
Проверить подмапленные, отсутствующие и субституционные диски. Все, которые не используются, а не используются почти всегда все - похерить.
Проверить сколько и чего прописано в патх. Почистить. Вплоть до того, что создать юзера только под разработку.
Часть четвертая.
посмотреть, куда пишутся обьектники и куда сбрасываются готовые либу и ехешники. По идее - обьектники должны писаться не на тотже физический диск где исходники и куда пойдут готовости.
Во времена когда винчестера на ПК были в диковикнку, Я пользовал такую штуку как RAM(virtual)-диск для обьетных и других файлов временного хранения - порядка на 3-4 по производительности. Как сейчас - не тестил.
NEW 21.03.13 22:04
in Antwort AlexNek 21.03.13 21:43
сделали ссылку на сетевой диск
------
Это - пустяк... У меня разок в путях оказалась ссылка на несуществующий дискетник... 40 минут вместо 15 секунд...
------
Это - пустяк... У меня разок в путях оказалась ссылка на несуществующий дискетник... 40 минут вместо 15 секунд...
NEW 21.03.13 22:05
in Antwort anly 21.03.13 21:46
Просто убей все подмапленне диски. Какие будут нужны - сделай шорткаты...
NEW 21.03.13 22:11
in Antwort Murr 21.03.13 22:05, Zuletzt geändert 21.03.13 22:25 (anly)
чувствую что здесь что-то существенное...
к сожалению я не знаю как их убить. И пока не понимаю о том ли идет речь что я подозреваю.
А именно: эксплорер показывает с десяток сетевых дисков, которыми я обычно не пользуюсь, а редко пользуюсь парочкой.
Как их убить и как оставить возможность ими пользоваться если приспичит?
А может есть способ сказать ВизуалСтудии не обращать на них внимание?
к сожалению я не знаю как их убить. И пока не понимаю о том ли идет речь что я подозреваю.
А именно: эксплорер показывает с десяток сетевых дисков, которыми я обычно не пользуюсь, а редко пользуюсь парочкой.
Как их убить и как оставить возможность ими пользоваться если приспичит?
А может есть способ сказать ВизуалСтудии не обращать на них внимание?
Проклят нарушающий межи ближнего своего (Втор.27:17)
21.03.13 22:36
in Antwort anly 21.03.13 22:11
не знаю как их убить.
------
Под 7й Я не делал.
В общем случае - map/unmap - для ресурса. Потряси своего админа на предмет что где не нужно.
может есть способ сказать
------
Насколько Я знаю - нету - оно на уровне сыстемы сканится...
с десяток сетевых дисков
-----
Ну каждый и проверяется на наличие нужных папок/файлов...
------
Под 7й Я не делал.
В общем случае - map/unmap - для ресурса. Потряси своего админа на предмет что где не нужно.
может есть способ сказать
------
Насколько Я знаю - нету - оно на уровне сыстемы сканится...
с десяток сетевых дисков
-----
Ну каждый и проверяется на наличие нужных папок/файлов...
NEW 22.03.13 09:24
in Antwort anly 21.03.13 20:13
IMHO, минимум 8гб ОЗУ, проект на SSD.
Вот статья на эту тему.
> Диски для Виндовса и для проэкта раздельные (логически. физически - один), каждый гдето 120 ГБ. Обое наполовину пустые.
Неуверен, что перенос проекта на отдельный старорежимный HDD, значительно ускорит процесс. Из личного опыта, есть проект в сумме 9ГБ (исходники, объектники, библиотеки и пр.) на отдельном физическом HDD, х32 Win, 4 ядра ЦПУ, 4ГБ ОЗУ, много boost (сильно тормозит процесс компиляции). Компиляция занимает 25 мин.
> 1) стоит ли дефрагментировать диск проэкта, на котором каждой компиляцией создаётся/модифицируется куча файлов (напр. obj)
> это может улучшить производительность если коприлирую я каждый день и не мало раз? (честно я не заметил улучшения, почти)
Думаю, что значительной прибавки это не даст.
> Главный вопрос: откуда взялись тормоза?
Есть вероятность от boost'а.
Вот статья на эту тему.
> Диски для Виндовса и для проэкта раздельные (логически. физически - один), каждый гдето 120 ГБ. Обое наполовину пустые.
Неуверен, что перенос проекта на отдельный старорежимный HDD, значительно ускорит процесс. Из личного опыта, есть проект в сумме 9ГБ (исходники, объектники, библиотеки и пр.) на отдельном физическом HDD, х32 Win, 4 ядра ЦПУ, 4ГБ ОЗУ, много boost (сильно тормозит процесс компиляции). Компиляция занимает 25 мин.
> 1) стоит ли дефрагментировать диск проэкта, на котором каждой компиляцией создаётся/модифицируется куча файлов (напр. obj)
> это может улучшить производительность если коприлирую я каждый день и не мало раз? (честно я не заметил улучшения, почти)
Думаю, что значительной прибавки это не даст.
> Главный вопрос: откуда взялись тормоза?
Есть вероятность от boost'а.