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

132

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

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

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

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

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

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

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

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

По-прежнему не копирует компиляцию, но помогает каждый бит.

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

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

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

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

johnc
источник
Ух ты, я думал, что 20 секунд компиляции - это ужасно долго.
Джаред Апдайк
По возможности старайтесь избегать множественных решений, поскольку рефакторинг становится намного сложнее.
Ян Рингроуз
Вы можете использовать VSS вне Visual-Studio, чтобы избежать накладных расходов на общение Visual-Studio с VSS.
Ян Рингроуз
Как насчет ресурсов? Представляю, они замедляют процесс. Я видел коммерческое программное обеспечение с exe-файлами размером с компакт-диск, которое вы запускаете с компакт-диска (а не установки). Они были полны видео, аудио и изображений. Итак, программное обеспечение было всего лишь одним файлом ....
Bitterblue

Ответы:

74

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

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

  • Установите исправление Microsoft 935225 .
  • Установите исправление Microsoft 947315 .
  • Используйте настоящий многоядерный процессор (т. Е. Intel Core Duo 2; не Pentium 4 HT).
  • Используйте 3 параллельных сборки. В Visual Studio 2005 вы найдете опцию в Инструменты> Параметры ...> Проекты и решения> Сборка и запуск> максимальное количество параллельных сборок проекта .
  • Отключите антивирусное программное обеспечение для файлов .ilk, .pdb, .cc, .h и проверяйте наличие вирусов только при изменении . Отключите сканирование каталога, в котором находятся ваши источники. Не делай глупостей.
  • Сохраните и создайте код Chromium на втором жестком диске. Это не сильно ускорит сборку, но, по крайней мере, ваш компьютер будет продолжать реагировать, когда вы выполняете синхронизацию gclient или сборку.
  • Регулярно выполняйте дефрагментацию жесткого диска.
  • Отключить виртуальную память.
Nate
источник
30
Под отключением виртуальной памяти я предполагаю, что вы имеете в виду отключить своп, отключение виртуальной памяти потребует перезаписи всей ОС; p
Джозеф Гарвин
9
Это похоже на ответ, направленный на сборки C ++, а не сборки C #,
Ян Рингроуз,
2
Ты прав! Хотя я должен отметить, что я ответил до того, как он указал C #, и некоторые исправления все еще применяются.
Nate
* Сохраните проект на SSD-диске. * Отключите индексацию Windows (в диспетчере файлов щелкните правой кнопкой мыши папку решения, Свойства-> Дополнительно, снимите флажок «Разрешить файлы ... проиндексированы ...»)
+1 Если у вас достаточно оперативной памяти, они сохраняют проект на RAM-диске. Это может значительно улучшить производительность до 50-70%. проверьте codeproject.com/Articles/197663/Speed-up-Visual-Studio-Builds для получения дополнительной информации
Арджун Вачани,
58

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

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

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

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

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

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

Gone Coding
источник
2
Также использовал эту технику, с решением, имеющим 180 проектов. Это очень помогло. Вы даже можете использовать командную строку для создания всего решения `devenv.exe / build yoursolution / takealookatthedoc`` ... так что вы работаете только с несколькими проектами, а при необходимости вы перекомпилируете все решение в строке cmd (после получить последнюю версию для примера)
Стив Б
У вас есть ссылки, описывающие, как это делается? Я не имею в виду писать плагин VS. Скорее, описываются конкретные задачи
Дэниел Дайсон
@ Дэниел Дайсон: Насколько подробно вам нужно знать? Все сводится к 1) загрузке любых выгруженных проектов 2) повторению иерархии решений / проектов / ссылок 3) поиску проектов со ссылками на другие проекты 4) изменению «выбранных» ссылок на ссылки DLL (с ​​правильными путями подсказок), затем 5) выгрузка нежелательных проектов. «Выбрано» можно либо через меню содержимого (т.е. выбранные проекты (проекты)), либо через дерево флажков для выбора элементов.
Gone Coding
Спасибо. Этого должно быть достаточно, чтобы я начал.
Дэниел Дайсон,
1
@HiTechMagic Ах, жаль это слышать. Но да, выпуск его с открытым исходным кодом означает, что мы все можем помочь. Пожалуйста, разместите здесь ссылку на github, если вы ее выпустите.
georgiosd
24

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

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

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

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

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

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

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

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

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

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

Ким
источник
4
Как SSD по сравнению с raptor. Еще быстрее
догадываюсь
4
Ага. Мой ноутбук с Intel X25M во всех отношениях быстрее моего настольного компьютера с WD Raptor.
CAD-парень
4
Это может показаться удивительным, но в настоящее время не стоит инвестировать в привод на 10000 об / мин. Причина в том, что лучшие приводы на 7200 об / мин быстрее на внешнем ободе. Итак, что нужно сделать, это создать небольшой раздел. Первый раздел находится на внешнем ободе, этот раздел будет быстрее, чем диск со скоростью 7200 об / мин, плюс у вас все еще есть место для второго большого раздела для хранения вещей.
darklon
2
@cornelius: могу я получить ссылку, которая разъясняет вашу точку зрения? Единственный способ, которым внешний обод 7200 мог быть быстрее, чем внешний обод 10000, был бы, если бы 7200 имели тенденцию к радиусу, что, возможно, и могло быть, но на самом деле этот трюк был бы своего рода взломом и не принесет пользы. для остальной части жесткого диска 7200, который находится ниже равновесного радиуса, при котором два диска имеют равную тангенциальную скорость.
eremzeit 09
2
Я с CADbloke. Мы использовали raptors до прошлого года, когда цена на твердотельные накопители снизилась до такой степени, что мы использовали твердотельные накопители только для основных накопителей в наших ноутбуках / настольных компьютерах. Увеличение скорости является фантастическим и, несомненно, является самым большим фактором, влияющим на то, сколько времени потребуется для компиляции наших решений.
NotMe
16

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

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

Алекс Дэвис
источник
Разве это не то, что уже делает VS? Или вы имеете в виду, что неактуальные изменения, такие как комментарии и т. Д., Отбрасываются?
nawfal
1
Redgate, к сожалению, остановил работу над демоном .net, поэтому он не работает выше VS 2013
Роберт Иванц
14

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

jdelator
источник
2
... для папки кода / компиляции. Превращение антивирусной защиты в правило общего охвата - не лучшая идея. : o)
Бретт Ригби
5
Вам действительно не нужно выключать его, обычно достаточно его правильно настроить. Добавьте исключения для типов файлов, с которыми работает компилятор / компоновщик. В некоторых антивирусных пакетах эти исключения добавлены по умолчанию, в некоторых - нет.
darklon
@cornelius Какая правильная конфигурация антивируса? Можете ли вы предоставить детали? (может быть, в отдельный вопрос?)
Павел Радзивиловский
@Pavel: Ну, исключите типы файлов, с которыми работает компилятор, для C ++ это будут такие вещи, как .o, .pdb, .ilk, .lib, .cpp, .h. Кроме того, некоторые антивирусные программы (например, Avira AntiVir) позволяют настроить сканирование файлов на чтение, запись или и то, и другое. Настройка сканирования при чтении даст вам 99% защиту.
darklon
12

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

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

Аку
источник
Установка IncrediBuild на несколько запасных ПК сократила время компиляции в 10 или более раз для нашего проекта C ++ практически без усилий по администрированию.
Stiefel
был такой же опыт аку ... однако связь все еще была проблемой хе-хе
Пол Кэрролл
Если вы идете по этому пути, то подойдет просто пара выделенных серверов сборки. Однако похоже, что OP пытался исправить время сборки на локальных машинах разработчика.
NotMe
11

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

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

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

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

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

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

Шон
источник
8

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

Кристофер Джонсон
источник
Если вам подходят предварительно скомпилированные заголовки, то это хороший трюк, но они работают только в том случае, если вы можете создать сильное общее подмножество заголовков, которое редко меняется. Если вам постоянно приходится предварительно компилировать заголовки большую часть времени, когда вы строите, вы ничего не сохраняете.
Том Свирли
7

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

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

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

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

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

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

Hace
источник
7

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

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

GeekyMonkey
источник
Вы можете объяснить, почему это быстрее? «Ссылки на проекты» подразумевают создание проекта (что намного медленнее, чем прямая ссылка на DLL).
Gone Coding
6

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

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

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

Эд С.
источник
1
Быть осторожен. В 2008 году есть ошибка, которая обрезает сборки. MS говорят, что не исправят до vs2010. Это ужасная проблема, потому что она обрезает файлы .obj, вызывая постоянные сбивающие с толку проблемы сборки. вы были предупреждены. ;) social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/…
Джастин
6

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

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

Thomas K
источник
5

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

tools-> options-> Настройки проекта VC ++ -> Build Timing = Yes сообщит вам время сборки для каждого vcproj.

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

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

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

Павел Радзивиловский
источник
5

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

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

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

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

Джонатан
источник
По моему опыту, RAM-диски не помогают во времени сборки VS, и они доставляют боль, потому что вам нужно воссоздавать их каждый раз, когда ваш компьютер перезагружается или выходит из строя. См. Сообщение в блоге здесь: josephfluckiger.blogspot.com/2009/02/…
BrokeMyLegBiking
3

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

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

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

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

Weeble
источник
Я уволился с работы, потому что это было проблемой некоторое время назад, но на моей новой должности это именно то, что мы реализовали! Приветствия. JC
johnc
2

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

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

Адам Пирс
источник
DLL (и ее различные собратья любят разделяемые библиотеки) сегодня почти всегда плохая идея для разработчика приложений. Исполняемые файлы имеют небольшие размеры, даже если вы подключаете каждую последнюю используемую библиотеку, и объем памяти, который вы экономите, разделяя код, также невелик. Библиотеки DLL восходят к тем временам, когда объем программного кода в памяти и на диске имел ключевое значение, но размер данных, памяти и диска рос намного быстрее, чем размер программ.
Том Свирли
2

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

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

Shog9
источник
Конечно, мы можем отключить интеграцию с VSS и вместо этого использовать Source Safe UI. Хорошая мысль
Джон С
2

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

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

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

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

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

Дэвид Л. Моррис
источник
2

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

GeekyMonkey
источник
1

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

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

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

Даниэль Аугер
источник
1

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

То есть:

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

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

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

Брамха Гош
источник
1
Если бы это было так, решение никогда бы не компилировалось.
Майкл
@Michael будет компилироваться, если вы укажете dll в каталоге отладки вместо использования ссылок на проекты.
Калеб Джарес,
1

Одна более дешевая альтернатива Xoreax IB - это использование так называемых сборок убер-файлов. По сути, это файл .cpp с

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

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

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

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

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

Марк
источник
1

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

Крис О
источник
1

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

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

Тонкий.

JBRWilkinson
источник
Скорость движения, безусловно, является важным фактором
Джон
Не оптимально настроен. 2 ГБ ОЗУ слишком мало для начала.
TomTom
1

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

Павел Радзивиловский
источник
1

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

darklon
источник
1

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

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

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

haughtonomous
источник
У меня тоже была эта проблема с VS2005 - определенно пейджинг
johnc
1

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

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

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

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

Эрик Ахо
источник
0

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

логан
источник
Там должна быть еще одна проблема, 2 проекта должны нормально работать на приличной машине
johnc
0

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

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

По-прежнему не копирует компиляцию, но помогает каждый бит.

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

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

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

оборота johnc
источник