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

Question

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

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

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

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

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

EDIT:

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

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

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

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

* 1029 Временное решение *

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

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

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

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

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

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

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

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

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