У нас очень медленное время компиляции, которое может занять более 20 минут на двухъядерных 2GHz, 2G Ram машинах.
Во многом это связано с размером нашего решения, которое выросло до 70+ проектов, а также с VSS, который сам по себе является узким местом, когда у вас много файлов. (замена VSS, к сожалению, не вариант, поэтому я не хочу, чтобы это перешло в VSS bash)
Мы смотрим на слияние проектов. Мы также рассматриваем возможность использования нескольких решений для обеспечения большего разделения задач и ускорения времени компиляции для каждого элемента приложения. Это, как я вижу, станет адом DLL, когда мы попытаемся синхронизировать ситуацию.
Мне интересно знать, как другие команды справились с этой проблемой масштабирования, что вы делаете, когда ваша кодовая база достигает критической массы, которую вы тратите половину дня, наблюдая, как строка состояния доставляет сообщения компиляции.
UPDATE
Я забыл упомянуть, что это решение C #. Спасибо за все предложения C ++, но прошло несколько лет с тех пор, как мне пришлось беспокоиться о заголовках.
EDIT:
Хорошие предложения, которые помогли до сих пор (не говоря уже о том, что нет других хороших предложений ниже, только то, что помогло)
- Новый 3GHz ноутбук - сила потерянного использования творит чудеса при стремлении к управлению
- Отключить антивирус во время компиляции
- «Отключение» от VSS (фактически от сети) во время компиляции - я могу заставить нас полностью удалить интеграцию с VS-VSS и придерживаться использования интерфейса VSS
Все еще не перебирая фишки через компиляцию, но каждый бит помогает.
Орион упомянул в комментарии, что у дженериков тоже может быть игра. Судя по моим тестам, производительность кажется минимальной, но недостаточно высокой, чтобы быть уверенной - время компиляции может быть непоследовательным из-за активности диска. Из-за нехватки времени мои тесты не включали столько Generics или столько кода, сколько могло бы появиться в работающей системе, чтобы они могли накапливаться. Я бы не стал использовать дженерики там, где они должны использоваться, только для производительности во время компиляции
* 1029 Временное решение *
Мы тестируем практику построения новых областей приложения в новых решениях, импортируя в них новейшие библиотеки по мере необходимости, интегрируя их в более крупные решения, когда мы довольны ими.
Мы также можем делать то же самое с существующим кодом, создавая временные решения, которые просто инкапсулируют области, над которыми мы должны работать, и выбрасывая их после реинтеграции кода. Нам нужно взвесить время, которое потребуется для реинтеграции этого кода, и время, которое мы получаем, если у Рипа Ван Винкла не было опыта быстрой перекомпиляции во время разработки.