Вход на сайт
ускорить работу компайлера
NEW 21.03.13 20:13
Последний раз изменено 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
в ответ anly 21.03.13 20:13
Винда 64 или 32 бита?
Для 64 бит на СИ сервере мы получили значительное увеличение скорость компиляции только увеличив память до 8 гигов.
Попробуйте еще удалить все файлы из мусорной корзины. Когда там собирается солидное количество файлов могут быть придичные тормоза.
Компайлер то какой и что за язык?
Для 64 бит на СИ сервере мы получили значительное увеличение скорость компиляции только увеличив память до 8 гигов.
Попробуйте еще удалить все файлы из мусорной корзины. Когда там собирается солидное количество файлов могут быть придичные тормоза.
Компайлер то какой и что за язык?
21.03.13 20:50
в ответ 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
в ответ anly 21.03.13 20:13
Судя по ссылкам он обьектные файлы - пишешь Плюсах.
В плюсах, насколько помню, есть фишка с включаемыми файлами - добавляется чуток - время растет экспоненциально.
Борланд в свое время делал предкомпиляцию заголовочных файлов. Есть ли такое в ВС - не знаю - рой настройки.
Если нету, то можно экономить на компиляции путем включения цпп-файлов как и заголовочных... морока, но раза в три
ускорить получалось...
Так, надо сбегать недалеко - допишу потом...
В плюсах, насколько помню, есть фишка с включаемыми файлами - добавляется чуток - время растет экспоненциально.
Борланд в свое время делал предкомпиляцию заголовочных файлов. Есть ли такое в ВС - не знаю - рой настройки.
Если нету, то можно экономить на компиляции путем включения цпп-файлов как и заголовочных... морока, но раза в три
ускорить получалось...
Так, надо сбегать недалеко - допишу потом...
NEW 21.03.13 21:16
точно - в плюсах.
шарп (пользуюсь только дома, а на работе только для тестов) гораздо проворнее (впрочем больших проэктов на шарпе я не пробовал).
некоторые проэкты солюшена у нас используют boost. Так вот они компилируются ощутимо дольше.
Сам я не люблю boost. Как минимум там где используется у нас. Это похоже как на танке в булочную съездить что за углом, вместо велосипеда. Неоправданная сложность, где можно сделать просто. В callstack дебагера смотреть страшно: десяток вызовов вместо одного (если бы без boost).
Кстати boost - это тоже новое что появилось в нашем солюшене за пол года..
шарп (пользуюсь только дома, а на работе только для тестов) гораздо проворнее (впрочем больших проэктов на шарпе я не пробовал).
некоторые проэкты солюшена у нас используют boost. Так вот они компилируются ощутимо дольше.
Сам я не люблю boost. Как минимум там где используется у нас. Это похоже как на танке в булочную съездить что за углом, вместо велосипеда. Неоправданная сложность, где можно сделать просто. В callstack дебагера смотреть страшно: десяток вызовов вместо одного (если бы без boost).
Кстати boost - это тоже новое что появилось в нашем солюшене за пол года..
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:39
в ответ AlexNek 21.03.13 21:32
решена просто: сразу после stdafx.h стоить #pragma hdrstop.
После которого обычно еще куча инклудов.
Весь проэкт уже 20 лет как живёт, а порядок в нём похоже только я и навожу, беря на себя ответсвенность и риск.
boost включен в предкомпилированный заголовок, но видно он слишком большой.
После которого обычно еще куча инклудов.
Весь проэкт уже 20 лет как живёт, а порядок в нём похоже только я и навожу, беря на себя ответсвенность и риск.
boost включен в предкомпилированный заголовок, но видно он слишком большой.
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 21:44
Проэкт после успешной компиляции на диске занимает около 10 гб ( это включая исходники и obj и прочее)
на диске обычно имеется штук 5 версий проэкта (кроме других редко используемых проэктов). которые переодически удаляются, и заново грузятся/билдятся с соурсконтрола.
В ответ на:
загрузить их в эти
пардон, не понял: "их" - это что? загрузить их в эти
Проэкт после успешной компиляции на диске занимает около 10 гб ( это включая исходники и obj и прочее)
на диске обычно имеется штук 5 версий проэкта (кроме других редко используемых проэктов). которые переодически удаляются, и заново грузятся/билдятся с соурсконтрола.
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 22:00
в ответ 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:11
чувствую что здесь что-то существенное...
к сожалению я не знаю как их убить. И пока не понимаю о том ли идет речь что я подозреваю.
А именно: эксплорер показывает с десяток сетевых дисков, которыми я обычно не пользуюсь, а редко пользуюсь парочкой.
Как их убить и как оставить возможность ими пользоваться если приспичит?
А может есть способ сказать ВизуалСтудии не обращать на них внимание?
к сожалению я не знаю как их убить. И пока не понимаю о том ли идет речь что я подозреваю.
А именно: эксплорер показывает с десяток сетевых дисков, которыми я обычно не пользуюсь, а редко пользуюсь парочкой.
Как их убить и как оставить возможность ими пользоваться если приспичит?
А может есть способ сказать ВизуалСтудии не обращать на них внимание?
Проклят нарушающий межи ближнего своего (Втор.27:17)
NEW 21.03.13 22:36
в ответ anly 21.03.13 22:11
не знаю как их убить.
------
Под 7й Я не делал.
В общем случае - map/unmap - для ресурса. Потряси своего админа на предмет что где не нужно.
может есть способ сказать
------
Насколько Я знаю - нету - оно на уровне сыстемы сканится...
с десяток сетевых дисков
-----
Ну каждый и проверяется на наличие нужных папок/файлов...
------
Под 7й Я не делал.
В общем случае - map/unmap - для ресурса. Потряси своего админа на предмет что где не нужно.
может есть способ сказать
------
Насколько Я знаю - нету - оно на уровне сыстемы сканится...
с десяток сетевых дисков
-----
Ну каждый и проверяется на наличие нужных папок/файлов...
NEW 22.03.13 09:24
в ответ 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'а.