Ответ 1

Команда Chromium.org указала несколько вариантов ускорения сборки (на данный момент примерно на полпути вниз):

В порядке убывания ускорения:

• Установите исправление Microsoft 935225.
• Установите исправление Microsoft 947315.
• Используйте настоящий многоядерный процессор (то есть Intel Core Duo 2, а не Pentium 4 HT).
• Используйте 3 параллельных сборки. В Visual Studio 2005 вы найдете опцию в Инструменты > Параметры... > Проекты и решения > Сборка и запуск > максимальное количество параллельных проектов.
• Отключите антивирусное программное обеспечение для файлов .ilk,.pdb,.cc,.h и проверьте наличие вирусов на изменении. Отключите сканирование каталога, в котором находятся ваши источники. Не делайте ничего глупого.
• Сохраните и создайте код Chromium на втором жестком диске. Это не ускорит сборку, но, по крайней мере, ваш компьютер будет реагировать, когда вы выполняете синхронизацию gclient или сборку.
• Регулярно дефрагментируйте свой жесткий диск.
• Отключить виртуальную память.

Ответ 2

У нас есть почти 100 проектов в одном решении, а время сборки - только секунды:)

Для локальных сборок разработки мы создали приложение Visual Studio Addin, которое меняет Project references на DLL references и выгружает нежелательные проекты (и возможность их возврата обратно).

• Создайте все наше решение после
• Разгрузите проекты, над которыми мы сейчас не работаем, и изменим ссылки на все ссылки на DLL-ссылки.
• Перед регистрацией изменений все ссылки возвращаются из DLL в ссылки на проекты.

Наши сборки теперь занимают только секунды, когда мы работаем только по нескольким проектам за раз. Мы также можем отлаживать дополнительные проекты, поскольку они связаны с DLL отладки. Инструмент обычно занимает 10-30 секунд, чтобы сделать большое количество изменений, но вам не нужно часто это делать.

Обновление до 2015 года

Сделка, которую я сделал (в комментариях ниже), заключалась в том, что я выпустил бы плагин для Open Source, если он получит достаточный интерес. 4 года спустя он имеет всего 44 голоса (а Visual Studio теперь имеет две последующие версии), поэтому в настоящее время это проект с низким приоритетом.

Ответ 3

У меня была аналогичная проблема для решения с 21 проектом и 1/2 миллиона LOC. Самой большой разницей стало ускорение работы жестких дисков. Из монитора производительности "Сред. Disk Queue" значительно повысился бы на ноутбуке, указывая на то, что на жестком диске была шея бутылки.

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

1) Ноутбук, Core 2 Duo 2GHz, 5400 RPM Drive (не уверен в кеше. Был стандартным Dell Inspiron).

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

2) Рабочий стол (стандартная версия), Core 2 Duo 2.3Ghz, один 7200RPM накопитель 8 МБ кэш.

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

3) Desktop Core 2 Duo 3Ghz, один 10000 об/мин WD Raptor

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

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

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

Ответ 4

Для С#.NET builds вы можете использовать .NET Demon. Это продукт, который использует процесс сборки Visual Studio, чтобы сделать его быстрее.

Он делает это, анализируя сделанные вами изменения и строя только тот проект, который вы фактически изменили, а также другие проекты, которые действительно основывались на сделанных вами изменениях. Это означает, что если вы изменяете только внутренний код, нужно построить только один проект.

Ответ 5

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

Ответ 6

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

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

Ответ 7

Инструкции по сокращению времени компиляции Visual Studio на несколько секунд

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

Стратегия преодоления этого - отключить автоматические сборки эталонных деревьев. Для этого используйте "Configuration Manager" (Build/Configuration Manager... затем в раскрывающемся меню "Конфигурация Active", выберите "Создать" ), чтобы создать новую конфигурацию сборки под названием "ManualCompile", которая копирует из конфигурации Debug, но не установите флажок "Создать новые конфигурации проекта". В этой новой конфигурации сборки снимите флажок с каждого проекта, чтобы ни одна из них не создавалась автоматически. Сохраните эту конфигурацию, нажав "Закрыть". Эта новая конфигурация сборки добавляется в файл решения.

Вы можете переключиться с одной конфигурации сборки на другую с помощью раскрывающегося списка конфигурации сборки в верхней части экрана IDE (тот, который обычно показывает "Debug" или "Release" ). Эффективно эта новая конфигурация сборки ManualCompile сделает бесполезными опции меню Build для: "Build Solution" или "Rebuild Solution". Таким образом, когда вы находитесь в режиме ManualCompile, вы должны вручную создать каждый проект, который вы изменяете, что можно сделать, щелкнув правой кнопкой мыши по каждому затронутому проекту в обозревателе решений, а затем выбрав "Build" или "Rebuild". Вы должны увидеть, что общее время компиляции теперь будет всего лишь секунды.

Чтобы эта стратегия работала, необходимо, чтобы файл VersionNumber, содержащийся в файлах AssemblyInfo и GlobalAssemblyInfo, оставался статичным на машине разработчика (не во время сборки релиза, конечно), и что вы не подписываете свои DLL.

Потенциальный риск использования этой стратегии ManualCompile заключается в том, что разработчик может забыть компилировать требуемые проекты, и когда они запускают отладчик, они получают неожиданные результаты (невозможно подключить отладчик, файлы не найдены и т.д.). Чтобы этого избежать, лучше всего использовать конфигурацию сборки "Debug" для компиляции больших усилий по кодированию и использовать конфигурацию сборки ManualCompile во время модульного тестирования или для внесения быстрых изменений, которые имеют ограниченную область.

Ответ 8

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

Ответ 9

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

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

Мы думаем о другом решении, хотя.

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

Однако работа с двумя различными решениями потребует особого внимания. Разработчики могут быть склонны к фактической работе во втором решении и полностью пренебрегать первым. Поскольку первое решение с 70+ проектами будет решением, которое будет заботиться о вашей иерархии объектов, это должно быть решением, в котором ваш сервер-разработчик должен запускать все ваши unittests. Таким образом, сервер для Continuous Integration должен быть первым проектом/решением. Вы должны поддерживать свою иерархию объектов, правильно.

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

Ответ 10

Убедитесь, что ваши ссылки относятся к проектам, а не к DLL файлам в каталогах вывода библиотеки.

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

Ответ 11

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

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

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

Ответ 12

Я замечаю, что этот вопрос вечен, но тема по-прежнему представляет интерес сегодня. Одна и та же проблема немного меня укусила, и две вещи, которые улучшили производительность сборки, были наиболее важны: (1) использовать выделенный (и быстрый) диск для компиляции и (2) использовать один и тот же выводный файл для всех проектов и установить 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/

Ответ 13

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

tools- > options- > Настройки проекта VС++ → Время сборки = Да покажет вам время сборки для каждого vcproj.

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

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

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

Ответ 14

Прежде чем тратить деньги на инвестиции на более быстрые жесткие диски, попробуйте полностью создать проект на диске RAM (при условии, что у вас есть оперативная память). Вы можете найти различные свободные драйверы RAM-диска в сети. Вы не найдете никакого физического диска, включая SSD, которые быстрее, чем RAM-диск.

В моем случае проект, который занял 5 минут, чтобы построить 6-ядерный i7 на диске SATA с частотой 7200 об/мин с Incredibuild, был сокращен примерно на 15 секунд с использованием RAM-диска. Учитывая необходимость переустановки на постоянное хранилище и возможность потерянной работы, 15 секунд недостаточно стимулов для использования RAM-диска и, вероятно, не слишком много стимулов тратить несколько сотен долларов на накопитель с высоким RPM или SSD.

Небольшое усиление может указывать на то, что сборка была связана с процессором или что кэширование файлов Windows было довольно эффективным, но поскольку оба теста выполнялись из состояния, в котором файлы не были кэшированы, я сильно опираюсь на компиляторы с привязкой к процессору.

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

Ответ 15

Насколько велика ваша сборка для сборки после выполнения полной сборки? Если вы придерживаетесь настройки по умолчанию, то каждая собранная вами сборка скопирует все DLL-зависимости своих зависимостей и зависимостей зависимостей и т.д. С его каталогом bin. В моей предыдущей работе, когда я работал с решением из ~ 40 проектов, мои коллеги обнаружили, что самая дорогостоящая часть процесса сборки повторяла эти сборки снова и снова, и эта одна сборка могла генерировать гигабайты копий одной и той же DLL и снова.

Вот некоторые полезные советы Патрика Смаккии, автора книги NDepend, о том, что, по его мнению, должны и не должны быть отдельными сборками:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

В основном есть два способа обойти это, и у обоих есть свои недостатки. Один из них - уменьшить количество сборок, что, очевидно, очень много. Другое - это реструктурировать ваши каталоги сборки, чтобы все ваши папки bin были объединены, а проекты не копировали библиотеки DLL своих зависимостей - им это не нужно, потому что они все находятся в одном каталоге. Это значительно сокращает количество файлов, созданных и скопированных во время сборки, но их может быть сложно настроить и может с трудом вытащить только библиотеки DLL, необходимые для конкретного исполняемого файла для упаковки.

Ответ 16

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

Если вас беспокоит, что разные версии DLL перепутаны, используйте статические библиотеки.

Ответ 17

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

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

Ответ 18

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

Для работы и тестирования у меня есть еще один набор пакетных файлов для каждого приложения (или модуля или библиотеки), в котором также есть все настройки отладки, но они все равно вызывают те же файлы make. Я могу время от времени переключаться с DEBUG, а также принимать решения о создании или создании или, если я хочу также создавать библиотеки, от которых зависит модуль, и т.д.

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

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

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

Ответ 19

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

Ответ 20

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

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

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

Ответ 21

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

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

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

Вы платите за это так, будьте осторожны:

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

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

Ответ 22

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

То есть:

Проект A ссылается на проект B

Ссылки Project B Project C

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

Ответ 23

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

Ответ 24

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

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

Тонкое.

Ответ 25

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

Ответ 26

При выборе CPU: размер кеша L1, по-видимому, оказывает огромное влияние на время компиляции. Кроме того, обычно лучше иметь 2 быстрых ядра, чем 4 медленных. Visual Studio не использует дополнительные ядра очень эффективно. (Я основываю это на своем опыте с компилятором С++, но, вероятно, это также верно для С#.)

Ответ 27

Теперь я также уверен, что есть проблема с VS2008. Я запускаю его на двухъядерном ноутбуке Intel с 3G Ram, при этом антивирус отключается. Компиляция решения часто довольно гладкая, но если я отлаживаю последующую перекомпиляцию, она часто замедляется до обхода. Из непрерывного основного света диска видно, что есть узкое место диска ввода-вывода (вы также можете его услышать). Если я отменил сборку и завершение работы VS, активность диска прекратится. Перезагрузите VS, перезагрузите решение, а затем перестройте, и он намного быстрее. Unitl в следующий раз

Мои мысли в том, что это проблема подкачки памяти - у VS просто закончилась нехватка памяти, и O/S начинает замену страниц, чтобы попытаться создать пространство, но VS требует больше, чем может выполнить обмен файлами, поэтому он замедляется до ползать. Я не могу придумать никаких других объяснений.

VS определенно не является инструментом RAD, не так ли?

Ответ 28

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

• Новый ноутбук 3GHz - сила потерянного использования творит чудеса, когда водит к управлению
• Отключить Антивирус во время компиляции
• "Отключение" от VSS (фактически сети) во время компиляции - я могу заставить нас полностью удалить интеграцию VS-VSS и придерживаться использования VSS-интерфейса

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

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

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

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

Ответ 29

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

Ответ 30

Есть несколько вещей, которые я нашел полезными для создания С#/.NET:

• Объедините небольшие проекты с более крупными проектами, так как для создания одного проекта накладные расходы на проект превышены. (Используйте nDepend, если это необходимо для управления вызовами по слоям)

• Сделайте все наши проекты встроенными в какой-то выходной каталог, а затем установите "copy local" на false во всех ссылках на проект - это может привести к большой скорости из-за уменьшения IO.

• Поворот вашей проверки на вирусы, чтобы узнать, имеет ли это значение; если так найти более быструю проверку на вирусы или исключить "горячие" папки из проверки проверки на вирусы

• Используйте монитор perforce и внутренний инструмент sys, чтобы увидеть, как ваши компиляторы занимают так много времени.

• Подумайте о том, как диск с диском помещает ваш выходной каталог.

• Рассмотрим использование SSD

• Больше памяти может иметь большой эффект в разы - (уменьшите барабан в машине, если вы сильно замедлите работу, удалив маленький баран, вы можете получить большую скорость, добавив больше) Удалите ненужные ссылки на проекты (возможно, вам придется сначала удалить ненужные "usings" )

• Подумайте о том, как использовать инфраструктуру инъекций зависимостей и интерфейсы для вашего самого низкого уровня домена, поэтому перекомпиляция всего необходима только тогда, когда изменяется интерфейс - это может не сильно зависеть от того, как часто изменяется интерфейс.