Как уменьшить MSBuild раз

Question

Моя ситуация

В C# проекта Сейчас я работаю над мы имеем довольно большое решение (80+ проектов). Теперь время восстановления 5 минут + действительно становится проблемой при использовании MSBuild от Visual Studio 2008.

В анализе я на прошлой неделе выяснилось, что мое время сборки было потрачено следующим образом:

1. Копирование файлов в проекты и переписывание его проектов, которые зависят от него (CopyToLocal), и т.д. . (60%)

2. Вызов постройке для декомпиляции/компиляции. (20%)

3. Ведение фактической компиляции и т.д. (20%)

Помимо «обычной» проект bin\debug папки выход также копируются на внешний каталог, чтобы настроить основной ' загрузчик ". Основная структура программы немного как это:

\loader\bin\loader.exe 

\loader\plugin\plugin1\plugin1.dll 

\loader\plugin\plugin1\somedependency.dll 

Что я сделал

В попытке сделать что-то идет немного быстрее, я подумал о следующем:

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

2. Use parallelism (/m) for MSBuild. Это помогает очень мало в времени сборки.

3. Постарайтесь уменьшить зависимость между проектами, что всегда хорошо, конечно.

4. Инвестировать в оборудование. Я нашел research on solid-state drives, но это не кажется многообещающим.

Мой вопрос

Я также заметил, что, когда я внести изменения в проект, который находится в корне моего дерева зависимостей все становится перестраивать. Даже если изменение было только в «частной» части, и интерфейс проекта не изменился.

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

Можно ли изменить это на другое состояние? Например, контрольная сумма файла?

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

Answer 1

У нас также есть огромные решения. Построение и компиляция - все о I/O.

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

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

/m редко помогает при сборке .NET debug. Несколько недель назад я провел серию тестов и обнаружил незначительные отличия. Выводы:

• Потому что моя сборка ввода/вывода ограничено, используя /м: 2-4 делает отладку строит медленнее для меня.
• Релиз сборки обычно намного быстрее.
• Анализ кода добавляет много времени.

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

На сервере сборки это сложнее. Мы подумываем о создании параллельной параллельной линии CruiseControl.NET на разных машинах. Мы используем сборку VSTS, но это слишком дорого (и занимает много времени) для масштабирования по горизонтали.

Мои номера для ориентированных на детали людей. Конфигурации от самых медленных до самых быстрых, запуск msbuild «bigsolution.sln»/target: clean - между каждым.

1. /м: 4, отладки с кодом анализа 1:38
2. /м: 1, с отладки анализа кода 1:30
3. /м: 4, отладки, без анализа кода 1:30
4. /м: 1, отладки, без анализа кода 1:30
5. /м: 1, выпуск с кодом анализа: 1:30
6. /м: 4, выпуск с кодом анализа: 1:05
7. /m: 4, Release без анализа кода: 0:53

время сборки без восстановления или очистки: ~ 4-10 секунда

Answer 2

MSBuild построить время является многомерной задачей. Хорошей новостью является то, что ее легко решить:

В отличие от большинства процессов, запущенных на машине сборки, процессы сборки печально известны как CPU, RAM и I/O-consuming. Общий рецепт для ускорения MSBuild сборки является «получить лучшую машину можно купить за деньги», в частности:

1. CPU - по крайней мере, два Intel 3,0 ГГц Core 2 Duo.

2. Оперативная память - не менее 4 ГБ DDR3. Если это разработчик и сборщик, 64-разрядная ОС и 8   ГБ ОЗУ - лучший вариант.

3. HDD - самые быстрые варианты - это высокопроизводительный 3ware RAID-1 с бортовой батареей и включенным кэшем записи. Мощным SSD может быть другой вариант.

4. Сеть - не менее 1   Gbit/s card.

Эта простая аппаратная оптимизация может ускорить работу MSBuild в 2-3 раза.

Answer 3

Я работаю над проектами приложений на 500+ C#. Проекты скомпилированы параллельно, а copylocal - false. Время компиляции составляет около 37   мин без модульных испытаний и покрытия кода. 13   мин для инкрементной сборки без изменения кода.

Если отключить параллельную компиляцию и установить copylocal в true, время компиляции составляет 1   h 40   мин.

У меня есть другая конфигурация для локальной сборки, стробированной сборки и сборки сервера с фазой развертывания (ночные сборки).

Вот мой опыт: выходные файлы

1. Копирование в один каталог не является хорошей идеей, если вы хотите, чтобы построить свои проекты параллельно без CopyLocal установлен неверно. Мои сборки иногда блокировались, когда несколько проектов ссылались на одну и ту же сборку, и MSBuild пыталась скопировать эту ссылку в папку вывода одновременно. This solution был очень полезен для меня. Я установил copylocal в false для всех ссылок, а размер каталога моей сборки был опущен на 10x (в 10 раз меньше ввода-вывода). У меня есть другая настройка для локальной сборки и для сборки сервера. Различные настройки для стробированной сборки регистрации и для полной сборки развертывания.
2. Если я разрешаю параллельную сборку, сборки выполняются быстрее, гораздо быстрее. Если у вас есть сильный сервер сборки, ваша сборка /m:2 должна быть в 2 раза быстрее, чем /m:1. Он не имеет ничего общего с зависимостями между проектами (если для copylocal установлено значение false).
3. Вы должны уменьшить зависимости между проектами, если хотите иметь быструю инкрементную сборку. Это не влияет на полную сборку (copylocal false). Инкрементальное время компиляции зависит от измененного местоположения проекта в дереве сборки.

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

Запустите свою сборку два раза с диагностической детализацией без каких-либо изменений в вашем коде и проверьте «Целевое задание» CoreCompile «полностью», как я описал here. Вы можете иметь что-то не так в ваших файлах проекта, и ваши проекты перекомпилируются каждый раз. Если вы ничего не измените, ваш журнал сборки не должен содержать «полностью настраиваемые» записи «Создание цели» CoreCompile.

Наш сервер сборки - это виртуальная машина, а не реальная часть оборудования. Неплохо использовать VM для сервера сборки, но это было не мое решение.

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

Диски SSD чувствительны к высоким ввода-выводам в день. Это влияет на гарантию.

Я надеюсь, что это поможет кому-то ...;)

Answer 4

Если вы получили достаточный объем оперативной памяти и с помощью Visual C++ (не уверен, C#), вы могли бы ускорить вещи, копируя весь включать и Lib каталога в оперативной памяти водить машину.

Вы также можете разместить временные элементы сборки на диске RAM. Конечно, вам нужно огромное количество оперативной памяти. Для дисков и библиотек было бы достаточно 2 Гбайт ОЗУ. Но для временных файлов (* .obj и т. Д.) Это будет зависеть от проекта. Таким образом, это может быть от 1 до 4   ГБ дополнительных или более.