Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, AlexDP, Вы писали:
ADP>>Интересно, занимался ли кто-нибудь ускорением компиляции. ADP>>Если да, то как?
F>см. IncrediBuild
Спасибо. Интересно. Но мне надо для .НЕТ, а тут — только для С++.
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, AlexDP, Вы писали:
ADP>>Интересно, занимался ли кто-нибудь ускорением компиляции. ADP>>Если да, то как?
F>см. IncrediBuild
Ну и самое интересно. В нашем распоряжении только одна машина на каждого.
Так что перекладівание нагрузки на другие компі — не подойдет.
Здравствуйте, AlexDP, Вы писали:
ADP>Ну и самое интересно. В нашем распоряжении только одна машина на каждого. ADP>Так что перекладівание нагрузки на другие компі — не подойдет.
Но вы же, наверное, не всё время компилируете одновременно, а во время дизайна вполне можно пожертвовать частью ресурсов своей машины.
Иначе не понятно, за счёт чего вы хотели повысить скорость. Чудес не бывает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, frogkiller, Вы писали:
F>Здравствуйте, AlexDP, Вы писали:
ADP>>Ну и самое интересно. В нашем распоряжении только одна машина на каждого. ADP>>Так что перекладівание нагрузки на другие компі — не подойдет.
F>Но вы же, наверное, не всё время компилируете одновременно, а во время дизайна вполне можно пожертвовать частью ресурсов своей машины. F>Иначе не понятно, за счёт чего вы хотели повысить скорость. Чудес не бывает.
Ну, кэш там оптимизировать. Сделать многопоточную компиляцию (уже нашел как). И т.п.
Да и не согласятся мои товарищи учавствовать в эксперименте.
Здравствуйте, AlexDP, Вы писали:
ADP>Ну, кэш там оптимизировать. Сделать многопоточную компиляцию (уже нашел как). И т.п.
Алексей, у нас тоже тормоза при работе с большим солюшеном в Visual Studio 2005 — свободно, гибко, быстро работать, строить, отлаживать — очень неудобно. И как раз пытаюсь узнать, как можно ускорить этот процесс.
Вы написали про многопоточную компиляцию — подскажите, пожалуйста, это возможность самой студии?
Обнаружили ли вы какие-нибудь еще способы ускорения работы с большим солюшеном?
Здравствуйте, michag, Вы писали:
M>Здравствуйте, AlexDP, Вы писали:
ADP>>Ну, кэш там оптимизировать. Сделать многопоточную компиляцию (уже нашел как). И т.п.
M>Алексей, у нас тоже тормоза при работе с большим солюшеном в Visual Studio 2005 — свободно, гибко, быстро работать, строить, отлаживать — очень неудобно. И как раз пытаюсь узнать, как можно ускорить этот процесс.
M>Вы написали про многопоточную компиляцию — подскажите, пожалуйста, это возможность самой студии?
только на уровне проектов ( к примеру у IB многопоточность работает на уровне файлов )
Здравствуйте, AlexDP, Вы писали:
ADP>Ну, кэш там оптимизировать. Сделать многопоточную компиляцию (уже нашел как). И т.п.
по моему студия устанавливает многопоточный режим компиляции автоматически и так же автоматически подстраиваетяс под количество процессоров на машинке, так что врядли поможет.
саму компиляцию можно ускорить если самые редко изменяемые проекты подключать в references как файлы, а не как проекты. компиляцию и скорость запуска проекта можно хорошо ускорить перенеся исходники на быстрый винт, или на RAID (0 или 1 — тот который повышает скорость а не надежность).
Здравствуйте, michag, Вы писали:
M>Здравствуйте, xtile, Вы писали:
X>>только на уровне проектов ( к примеру у IB многопоточность работает на уровне файлов )
M>А что такое IB? Это явно не investment banking ))
Здравствуйте, AlexDP, Вы писали:
ADP>В солюшене 30 проектов. ADP>Компиляция и запуск тормозят дико.
ADP>Простой запуск проекта из вижуал-студии, при том, что он ап-ту-дейт, занимает 1 минуту.
Очень вряд ли что каждый программист одновременно работает со всеми 30-ю проектами, да и неудобно это крайне. А что вам мешает разбить один большой солюшен на несколько меньших, причем в References вязаться на бинарные версии библиотек? При этом настроить систему сборки (MSBuild, NAnt по вкусу), чтобы весь проект либо отдельную его часть можно было собрать простой командой (такой как "go build" или "go build-commons").
Здравствуйте, michag, Вы писали:
M>Здравствуйте, AlexDP, Вы писали:
ADP>>Ну, кэш там оптимизировать. Сделать многопоточную компиляцию (уже нашел как). И т.п.
M>Алексей, у нас тоже тормоза при работе с большим солюшеном в Visual Studio 2005 — свободно, гибко, быстро работать, строить, отлаживать — очень неудобно. И как раз пытаюсь узнать, как можно ускорить этот процесс.
M>Вы написали про многопоточную компиляцию — подскажите, пожалуйста, это возможность самой студии?
tools-options-project and solutions — Build and run — maximum number of parallel projects build.
M>Обнаружили ли вы какие-нибудь еще способы ускорения работы с большим солюшеном?
1) Как уже сказали — более быстрый винт. У меня проц при компиляции не достигает 100% загруженности.
2) Обнаружил, что проект с NunitTest*ами ест раз в 5 больше времени, чем остальные. Отключил его билд. Но, понятное дело, что такое отключение
нельзя делать при полной тестировке программы, перед ее заливкой в репозиторий.
Здравствуйте, michag, Вы писали:
M>Здравствуйте, xtile, Вы писали:
M>>>А что такое IB? Это явно не investment banking )) X>>IncrediBuild, www.xoreax.com
M>А есть ли такая же штука для C#? IB работает вроде только для С++.
Если память не изменяет, то для C# нужно в первую очередь оптимизировать скорость дисковых операций. Т.е. raid из рапторов должен серьезно помочь.
На рам-диск можно перенести директории, bin и debug.
Их пути можно прописать в свойствах каждого проекта .
Но хотелось сделать то же самое но для всего солюшена, чтобы все bin и debug собирались на рам-диске.
Кто-то знает, как изменить пути bin и debug для всех проетов солюшена, меняя при этом только файл солюшена, но не меняя файлы проектов?
Здравствуйте, AlexDP, Вы писали:
ADP>На рам-диск можно перенести директории, bin и debug. ADP>Их пути можно прописать в свойствах каждого проекта .
ADP>Но хотелось сделать то же самое но для всего солюшена, чтобы все bin и debug собирались на рам-диске. ADP>Кто-то знает, как изменить пути bin и debug для всех проетов солюшена, меняя при этом только файл солюшена, но не меняя файлы проектов?
Здравствуйте, AlexDP, Вы писали:
ADP>>Но хотелось сделать то же самое но для всего солюшена, чтобы все bin и debug собирались на рам-диске. ADP>>Кто-то знает, как изменить пути bin и debug для всех проетов солюшена, меняя при этом только файл солюшена, но не меняя файлы проектов?
ADP>сорри, имелись ввиду директории bin и obj.
Можно попробовать с помощью junction замапить эти каталоги на другой (ram) диск. Тогда даже и файл солюшена трогать не нужно будет.
Сам не пробовал, но чем черт не шутит.
Здравствуйте, AlexDP, Вы писали:
ADP>В солюшене 30 проектов. ADP>Компиляция и запуск тормозят дико. ADP>Простой запуск проекта из вижуал-студии, при том, что он ап-ту-дейт, занимает 1 минуту. ADP>Интересно, занимался ли кто-нибудь ускорением компиляции. ADP>Если да, то как?
У нас больше сотни модулей. Полный билд на 4-х ядерном компе с RAID-ом занимает час. Проблема с запуском из-под VS решается тем, что не используем солюшен, где все модули. Обычно, работаешь над одним модулем, который непосредственно зависит лишь от нескольких других. Поэтому можно сделать солюшен лишь на нужные модули. Если надо перебилдить все, то запускаем специальный скрипт из command line-а.
Здравствуйте, AlexDP, Вы писали:
ADP>Пишем смарт-клайентовский проект.
ADP>В солюшене 30 проектов. ADP>Компиляция и запуск тормозят дико.
ADP>Простой запуск проекта из вижуал-студии, при том, что он ап-ту-дейт, занимает 1 минуту.
ADP>Интересно, занимался ли кто-нибудь ускорением компиляции.
ADP>Если да, то как?
ADP>По ускорению работы смарт-клаентов тоже интересно было бы послушать.
* thriving in a production environment *
