Многопроцессные сборки в Visual Studio 2010: стоит ли это?

Question

Я начал тестировать наше программное обеспечение C ++ с VS2010, и время сборки действительно плохое (30-45 минут, примерно вдвое больше, чем VS2005). Я читал о ключе / MP для многопроцессной компиляции. К сожалению, он несовместим с некоторыми функциями, которые мы используем во многом как #import, инкрементная компиляция и предварительно скомпилированные заголовки.

Был ли у вас похожий проект, в котором вы использовали переключатель / MP после отключения таких вещей, как предварительно скомпилированные заголовки? Вы получили более быстрые сборки?

Моя машина работает под управлением 64-разрядной Windows 7 на 4-ядерном компьютере с 4 ГБ ОЗУ и быстрым SSD-хранилищем. Отключен антивирусный сканер и довольно минимальная программная среда.

Редактировать: Мартин и jdehaan указали, что MP не является несовместимым с предварительно скомпилированными заголовками. Подробности здесь .

Answer 1

Вы уверены, что pch несовместим с / MP?
Конечно, вы можете сделать многоядерную сборку на vs2008 с помощью pch (хотя, как ни странно, только из IDE, а не из командной строки)

Answer 2

Определенно ДА . Я работал над большим приложением, создание которого заняло около 35 минут, когда что-то было изменено (в Visual Studio). Для этого мы использовали IncrediBuild (чтобы ускорить процесс компиляции с 35 до 5 минут) - чтобы он был действительно распределен. В вашем случае возможно, что ключ / MP будет иметь какое-то значение - но не так сильно по сравнению с distcc (Unix или совместимая среда) или IncrediBuild.

Answer 3

Мой собственный опыт работы с VS2005 и VS2008. В обоих случаях мы отключаем параллельные сборки, поскольку они не работают надежно для наших крупных проектов. Также с обоими, включение PCH дает большие преимущества в производительности. Хотя, если вы не используете PCH с VS2008, вы можете получить очень плохое время компиляции по сравнению с VS2005. Я не знаю, насколько это относится к VS2010.

РЕДАКТИРОВАТЬ: Были такие же проблемы с VS2010 ... но затем мы обновились с WinXP до Win7, и все наши проблемы Visual Studio исчезли, как в отношении стабильности и производительности. В моем предыдущем ответе параллельная сборка относится к параллелизму проекта msbuild, а в данном случае «большая» относится к большим решениям.

Answer 4

Сборки с несколькими машинами (с IncrediBuild) стоили этого для нас. Так что многопроцессорная сборка на одной машине вполне может стоить того.