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

https://stackoverflow.com/questions/55517

09-06-2019
|

Вопрос

Мы получаем очень медленное время компиляции, которое может занять более 20 минут на двухъядерных машинах с частотой 2 ГГц и 2G Ram.

Во многом это связано с размером нашего решения, которое выросло до 70+ проектов, а также с VSS, который сам по себе является узким местом, когда у вас много файлов.(к сожалению, замена VSS невозможна, поэтому я не хочу, чтобы это превратилось в VSS bash)

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

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

ОБНОВЛЯТЬЯ забыл упомянуть, что это решение C#.Спасибо за все предложения по C++, но прошло уже несколько лет с тех пор, как мне приходилось беспокоиться о заголовках.

РЕДАКТИРОВАТЬ:

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

Новый ноутбук с тактовой частотой 3 ГГц: потенциал потерянного использования творит чудеса при обращении к руководству
Отключить антивирус во время компиляции
«Отключение» от VSS (фактически сети) во время компиляции — я могу заставить нас полностью удалить интеграцию VS-VSS и придерживаться использования пользовательского интерфейса VSS.

Все еще не занимаюсь компиляцией, но все помогает.

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

ВРЕМЕННОЕ РЕШЕНИЕ

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

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

Решение

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

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

Установите исправление Microsoft 935225.

Установите исправление Microsoft 947315.

Используйте настоящий многоядерный процессор (т.Intel Core Duo 2;не Pentium 4 HT).

Используйте 3 параллельные сборки.В Visual Studio 2005 вы найдете эту опцию в Инструменты > Параметры...> Проекты и решения > Сборка и запуск > максимальное количество параллельных сборок проекта.

Отключите антивирусное программное обеспечение для файлов .ilk, .pdb, .cc, .h и проверяйте наличие вирусов только на изменить.Отключите сканирование каталога, в котором находятся ваши источники.Не делай ничего глупого.

Сохраните и создайте код Chromium на втором жестком диске.На самом деле это не ускорит сборку, но, по крайней мере, ваш компьютер будет продолжать реагировать, когда вы выполняете синхронизацию gclient или сборку.

Регулярно проводите дефрагментацию жесткого диска.

Отключите виртуальную память.

Другие советы

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

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

Создайте все наше решение один раз
Выгрузите проекты, над которыми мы сейчас не работаем, и измените все ссылки на проекты на ссылки на DLL.
Перед возвратом измените все ссылки обратно с DLL на ссылки проекта.

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

Обновление, май 2015 г.

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

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

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

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

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

2) Настольный компьютер (стандартная комплектация), процессор Core 2 Duo 2,3 ГГц, один диск со скоростью вращения 7200 об/мин, кэш-память 8 МБ.

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

3) Настольный процессор Core 2 Duo, 3 ГГц, одиночный WD Raptor, 10 000 об/мин

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

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

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

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

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

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

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

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

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

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

Стратегия решения этой проблемы — отключить автоматическое построение дерева ссылок.Для этого используйте «Диспетчер конфигурации» (Диспетчер сборки/конфигурации... затем в раскрывающемся списке «Конфигурация активного решения» выберите «Новый»), чтобы создать новую конфигурацию сборки под названием «ManualCompile», которая копирует конфигурацию отладки, но не устанавливайте флажок «Создать новые конфигурации проекта».В этой новой конфигурации сборки снимите флажки с каждого проекта, чтобы ни один из них не собирался автоматически.Сохраните эту конфигурацию, нажав «Закрыть».Эта новая конфигурация сборки добавляется в файл решения.

Вы можете переключаться с одной конфигурации сборки на другую через раскрывающийся список конфигурации сборки в верхней части экрана IDE (тот, который обычно показывает «Отладка» или «Выпуск»).По сути, эта новая конфигурация сборки ManualCompile сделает бесполезными параметры меню «Сборка» для:«Построить решение» или «Перестроить решение».Таким образом, когда вы находитесь в режиме ручной компиляции, вы должны вручную построить каждый изменяемый проект, что можно сделать, щелкнув правой кнопкой мыши каждый затронутый проект в обозревателе решений, а затем выбрав «Построить» или «Перестроить».Вы должны увидеть, что общее время компиляции теперь составит всего несколько секунд.

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

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

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

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

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

Хотя мы думаем о другом решении.

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

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

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

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

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

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

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

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

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

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

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

Инструменты-> Параметры-> VC ++ Настройки проекта-> Timing Build = Yes сообщит вам время для каждого VCPROJ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы также можете проверить наличие циклических ссылок на проекты.Когда-то для меня это было проблемой.

То есть:

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

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

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

Одной из более дешевых альтернатив 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.

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

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

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

Тонкий.

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

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

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

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

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

Ваша компания случайно не использует Entrust для своего решения PKI/шифрования?Оказывается, у нас была ужасная производительность сборки довольно большого веб-сайта, созданного на C#, и на Rebuild-All ушло более 7 минут.

Моя машина — i7-3770 с 16 ГБ оперативной памяти и твердотельным накопителем на 512 ГБ, поэтому производительность не должна была быть такой плохой.Я заметил, что время сборки было безумно быстрее на старой вторичной машине, собирающей ту же кодовую базу.Поэтому я запустил ProcMon на обеих машинах, профилировал сборки и сравнил результаты.

И вот, у медленно работающей машины было одно отличие — ссылка на Entrust.dll в трассировке стека.Используя эту недавно полученную информацию, я продолжил поиск в StackOverflow и нашел следующее: MSBUILD (VS2010) очень медленный на некоторых машинах.Согласно принятому ответу, проблема заключается в том, что обработчик Entrust обрабатывал проверки сертификата .NET вместо собственного обработчика Microsoft.Также предполагается, что Entrust v10 решает эту проблему, которая распространена в Entrust 9.

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

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

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

Новый ноутбук с тактовой частотой 3 ГГц: потенциал потерянного использования творит чудеса при обращении к руководству
Отключить антивирус во время компиляции
«Отключение» от VSS (фактически сети) во время компиляции — я могу заставить нас полностью удалить интеграцию VS-VSS и придерживаться использования пользовательского интерфейса VSS.

Все еще не занимаюсь компиляцией, но все помогает.

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow