Очень медленное время компиляции в 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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Тонкое.

Answer 5

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

Низкая производительность Visual Studio… Решено! 24 сентября 2014 года Узма Абиди

У меня сегодня была странная проблема, связанная с производительностью. Моя Microsoft Visual Studio, казалось, занимала слишком много времени, чтобы выполнять даже самые простые операции. Я погуглил и попробовал несколько идей, которые были у людей, такие как отключение надстроек или очистка списка последних проектов Visual Studio, но эти предложения, похоже, не решили проблему. Я вспомнил, что на веб-сайте Windows SysInternals есть инструмент Process Monitor, который отслеживает доступ к реестру и файлам любой запущенной программой. Мне показалось, что Visual Studio что-то замышляет, и Process Monitor должен помочь мне понять, что это было. Я скачал самую последнюю версию и, немного поигравшись с ее фильтрами экрана, запустил ее и, к своему ужасу, увидел, что Visual Studio работает очень медленно, потому что обращается к более чем 10 000 папок в C: \ Users \ krintoul \ AppData \ Local \ Microsoft \ WebSiteCache для большинства операций IDE. Я не уверен, почему было так много папок и, более того, не был уверен, что Visual Studio делает с ними, но после того, как я сжал эти папки и переместил их куда-то еще, производительность Visual Studio значительно улучшилась.

На веб-сайте Windows SysInternals есть ряд других полезных утилит для управления сетью, безопасности, системной информации и многого другого. Проверьте это. Я уверен, что вы найдете что-то ценное.

Answer 10

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

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

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

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

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

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