Очень медленное время компиляции на Visual Studio 2005

Также можно хотеть проверить на круговые ссылки проекта. Это была проблема для меня однажды.

Это:

Спроектируйте ссылочный Проект B

Ссылочный Проект C проекта B

Ссылочный Проект A проекта C

Если это - веб-приложение, устанавливание пакетной сборки к истинному может помочь в зависимости от сценария.

<compilation defaultLanguage="c#" debug="true" batch="true" >  

Можно найти обзор здесь: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Одна более дешевая альтернатива Xoreax IB является использованием того, что я называю сборками uber-файла. Это - в основном .cpp файл, который имеет

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Затем Вы компилируете uber единицы вместо отдельных модулей. Мы видели время компиляции от с 10-15 минут вниз к 1-2 минутам. Вы могли бы иметь к experiemnt с тем, сколько #includes на uber файл имеет смысл. Зависит от проектов. и т.д. Возможно, Вы включаете 10 файлов, возможно, 20.

Вы оплачиваете стоимость, так остерегайтесь:

1. Вы не можете щелкнуть правой кнопкой по файлу и сказать "компиляцию...", поскольку необходимо исключить отдельные cpp файлы из сборки и включать только uber cpp файлы
2. Необходимо остерегаться статических конфликтов глобальной переменной.
3. Когда Вы добавляете новые модули, необходимо усовершенствовать uber файлы

Это - своего рода боль, но для проекта, который в основном статичен с точки зрения новых модулей, начальная боль могла бы стоить того. Я видел этот удар метода IB в некоторых случаях.

Это уверено, что существует проблема с VS2008. Поскольку единственная вещь, которую я сделал, это должно установить VS2008 для обновления моего проекта, который был создан с VS2005. Я только получил 2 проекта в своем решении. Это не является большим. Компиляция с VS2005: Компиляция 30 секунд с VS2008: 5 минут

Хорошие предложения, которые помогли до сих пор (не говоря ниже нет других хороших предложений, если у Вас есть проблемы, я рекомендую читать затем, что помогло нам),

• Новый ноутбук на 3 ГГц - питание потерянного использования творит чудеса при хныкании к управлению
• Отключите Анти-Вирус во время компиляции
• При 'Разъединении' от VSS (на самом деле сеть) во время компиляции - я могу заставить нас удалять ИНТЕГРАЦИЮ VSS VS в целом и придерживаться использования UI VSS

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

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

Мы можем также сделать их то же к существующему коду путем создания временных решений, которые просто инкапсулируют области, мы должны продолжить работать, и выбрасывание их после реинтеграции кода. Мы должны уравновесить время, которое потребуется для реинтеграции этого кода против времени, которое мы получаем, не имея Rip Van Winkle как опыт с быстрой перекомпиляцией во время разработки.

Orion действительно упоминал в комментарии, что дженерики могут иметь игру также. От моих тестов, кажется, существует минимальный хит производительности, но не достаточно высоко к верному - время компиляции может быть непоследовательным из-за активности диска. Из-за ограничений времени, мои тесты не включали стольких Дженериков или такого количества кода, сколько появится в живой системе, так, чтобы мог накопиться. Я не избегал бы использования дженериков, где они, как предполагается, используются, только для производительности времени компиляции

У меня есть проект, который имеет 120 или больше exes, освобождает и dlls и занимает большое количество времени для создания. Я использую дерево пакетных файлов, которые называют make-файлы от одного основного пакетного файла. У меня были проблемы с нечетными вещами от возрастающего (или было это темпераментно), заголовки в прошлом, таким образом, я избегаю их теперь. Я делаю полную сборку нечасто и обычно оставляю это концу дня, в то время как я выхожу на прогулку в течение часа (таким образом, я могу только предположить, что он берет о получасе). Таким образом, я понимаю, почему это неосуществимо для работы и тестирования.

Для работы и тестирования у меня есть другой набор пакетных файлов для каждого приложения (или модуль или библиотека), которые также имеют в распоряжении все настройки отладки - но они все еще называют те же make-файлы. Я могу включить ОТЛАДКУ прочь время от времени и также выбрать сборки или делаю или если я хочу также создать, освобождает это, модуль может зависеть от и так далее.

Пакетный файл также копирует завершенный результат в (или несколько) тестовые папки. В зависимости от настроек это завершается за несколько секунд к минуте (в противоположность, говорит полчаса).

Я использовал другой IDE (Zeus), поскольку мне нравится управлять вещами как .rc файлы и на самом деле предпочитать компилировать из командной строки, даже при том, что я использую компиляторы MS.

Счастливый отправить пример этого пакетного файла, если кому-либо интересно.

Если это - C или C++, и Вы не используете предварительно скомпилированные заголовки, необходимо быть.

Отключите индексацию файловой системы на своих исходных каталогах (конкретно obj каталоги, если Вы хотите свой доступный для поиска источник),

Я отправил этот ответ первоначально здесь: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 можно найти много других полезных подсказок на той странице.

При использовании Visual Studio 2008 можно скомпилировать использование / флага MP для разрабатывания единственного проекта параллельно. Я считал, что это - также недокументированная функциональность в Visual Studio 2005, но никогда не судило меня.

Можно разработать несколько проектов параллельно при помощи флага/M, но это обычно уже устанавливается на количество доступных ядер на машине, хотя это только относится к VC ++, я верю.

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

Если Вы волнуетесь по поводу различных версий DLLs того, чтобы быть перепутанным, пользуетесь статическими библиотеками.

Удостоверьтесь, что Вашими ссылками являются Ссылки проекта, и не непосредственно к DLLs в выходных каталогах библиотеки.

Кроме того, имейте их набор для не копирования локально кроме где абсолютно необходимый (Основной проект EXE).

У нас было 80 + проекты в нашем основном решении, которое заняло приблизительно 4 - 6 минут для создания в зависимости от того, какая машина разработчик работал. Мы полагали что быть слишком длинными: для каждого теста это действительно съедает Ваш FTEs.

Таким образом, как получить более быстрое время изготовления? Поскольку Вы, кажется, уже знаете, что это - количество проектов, которые действительно повреждают buildtime. Конечно, мы не хотели избавляться от всех наших проектов и просто бросать все исходные файлы в один. Но у нас были некоторые проекты, которые мы могли объединить, тем не менее: Поскольку каждый "Проект репозитория" в решении имел свой собственный unittest проект, мы просто объединили все unittest проекты в один глобальный-unittest проект. Это сократило количество проектов приблизительно с 12 проектами и так или иначе сохранило 40% времени для создания всего решения.

Мы думаем о другом решении все же.

Вы также попытались установить новое (второе) решение с новым проектом? Это второе решение должно просто включать все файлы с помощью папок решения. Поскольку Вы могли бы быть удивлены видеть время изготовления того нового solution-with-just-one-project.

Однако работа с двумя различными решениями возьмет некоторое тщательное соображение. Разработчики могли бы быть склонны к на самом деле - работают во втором решении и полностью пропускают первое. Как первое решение с 70 + проекты будут решением, которое заботится о Вашей иерархии объектов, это должно быть решением, куда Ваш buildserver должен выполнить весь Ваш unittests. Таким образом, сервер для Интеграции Continous должен быть первым проектом/решением. Необходимо поддержать иерархию объектов, право.

Второе решение со всего одним проектом (который создаст mucho быстрее) будет, чем быть проектом, где тестирование и отладка будут сделаны всеми разработчиками. Необходимо заботиться о том, что они смотрели на buildserver хотя! Если что-нибудь повреждается, это ДОЛЖНО быть зафиксировано.

Выключите интеграцию VSS. У Вас не может быть выбора в использовании его, но DLLs "случайно" переименован все время...

И определенно проверьте свои предварительно скомпилированные настройки заголовка. Руководство Bruce Dawson немного старо, но все еще очень хорошо - проверяют его: http://www.cygnus-software.com/papers/precompiledheaders.html

Используйте распределенную компиляцию. Xoreax IncrediBuild может сократить время компиляции к нескольким минутам.

Я использовал его на огромном C\C ++ решение, которое обычно занимает 5-6 часов для компиляции. IncrediBuild помог уменьшить на этот раз до 15 минут.

Выключите свой антивирус. Это добавляет возрасты ко времени компиляции.

У меня была подобная проблема о решении с 21 проектом и 1/2 миллиона LOC. Самое большое различие получало более быстрые жесткие диски. От монитора производительности 'В среднем. Дисковая Очередь' значительно подпрыгнула бы на ноутбуке, указывающем, что жесткий диск был горлышком бутылки.

Вот некоторые данные для общего количества, восстанавливают времена...

1) Ноутбук, Core 2 Duo 2 ГГц, Диск на 5 400 об/мин (не уверенный в кэше. Был стандартный Dell Inspiron).

Восстановите Время = 112 секунд.

2) Рабочий стол (стандартная проблема), Core 2 Duo 2.3 ГГц, единственный Кэш Диска 8 МБ на 7200 об/мин.

Восстановите Время = 72 секунды.

3) Настольный Core 2 Duo 3 ГГц, единственный Хищник WD на 10 000 об/мин

Восстановите Время = 39 секунд.

Диск на 10 000 об/мин не может быть преуменьшен. Сборки, где значительно более быстрый плюс все остальное как отображающаяся документация, с помощью файлового менеджера были noticable более быстрый. Это было большое повышение производительности путем ускорения code-build-run цикла.

Учитывая то, что компании тратят на зарплаты разработчика, это безумно, насколько они могут ненужная покупка, оборудуя их теми же ПК как использование регистратора.

Если это проект C ++, вы должны использовать предварительно скомпилированные заголовки. Это сильно влияет на время компиляции. Не уверен, что на самом деле делает cl.exe (без использования предварительно скомпилированных заголовков), похоже, он ищет лоты заголовков STL во всех неправильных местах, прежде чем, наконец, перейти в правильное место. Это добавляет целые секунды к каждому компилируемому файлу .cpp. Не уверен, что это ошибка cl.exe или какая-то проблема STL в VS2008.

Если посмотреть на машину, на которой вы строите, оптимально ли она настроена?

Мы только что получили время сборки нашего крупнейшего продукта корпоративного масштаба на C ++ с 19 часов. От до 16 минут , убедившись, что установлен правильный драйвер фильтра SATA.

Тонкий.

Я заметил, что этому вопросу уже много лет, но тема все еще интересна. В последнее время я столкнулся с той же проблемой, и две вещи, которые улучшили производительность сборки больше всего, это (1) использование выделенного (и быстрого) диска для компиляции и (2) использование одной папки outputfolder для всех проектов, и установка CopyLocal в False для ссылок на проект.

Некоторые дополнительные ресурсы:

• https://stackoverflow.com/questions/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

Некоторые инструменты анализа:

инструменты->опции->Настройки проекта VC++ -> Время сборки = Да сообщит вам время сборки для каждого vcproj.

Добавьте переключатель /Bt в командную строку компилятора, чтобы увидеть, сколько занимает каждый файл CPP

Используйте /showIncludes, чтобы перехватывать вложенные включения (файлы заголовков, которые включают другие файлы заголовков) , и посмотрите, какие файлы могут сэкономить много операций ввода-вывода с помощью предварительных объявлений.

Это поможет вам оптимизировать производительность компилятора, устранив зависимости и пожиратели производительности.

В Visual Studio 2005 есть недокументированный переключатель /MP, см. http://lahsiv.net/blog/?p=40, который активирует параллельную компиляцию на основе файлов, а не проектов. Это может ускорить компиляцию последнего проекта, или, если вы компилируете один проект.