У нас есть большое решение Visual Studio 2005 С++/Mfc, 1 проект с примерно 1300 исходными файлами (примерно 650.h и 650.cpp файлов). Мы также используем Boost и несколько других библиотек (COM: MSXML, Office).
Недавно я добавил несколько примеров boost:: multi_index, чтобы немного ускорить работу. Все это компилируется большую часть времени. Но теперь, когда я выполняю полную (выпускную) перестройку, я получаю сбои компилятора в нескольких модулях.
Fatal Error C1060: "compiler is out of heap space"
Я уже пытался уменьшить количество включений в предварительно скомпилированном файле заголовка (удалено почти все, кроме стандартных заголовков MFC). Кроме того, я удалил параметр компилятора /Zm 200 (который нам раньше нужен, чтобы скомпилировать предварительно скомпилированный файл заголовка).
Странная вещь: когда я просто нажимаю F7 (сборку) после сбоя компилятора, процесс сборки продолжается без каких-либо проблем (или, по крайней мере, до следующего сбоя компилятора, где я снова нажимаю F7). Но было бы неплохо иметь возможность делать полную сборку без перерывов.
Могу ли я влиять на порядок сборки отдельных модулей? Таким образом, я мог бы поставить "проблемные" модули в начале процесса (и надеюсь, что сбои не просто перейдут на другие модули).
BTW: полная сборка занимает около 90 минут.
Update:
Спасибо за ответы. Я смог избавиться от сбоев компилятора и значительно сократить время компиляции. Вот что я сделал:
- Я удалил все входящие данные из предварительно скомпилированного файла заголовка, только стандартные заголовки окон /mfc остались такими, какими они были. Это заставило меня добавить еще больше включений в другие модули, но, в конце концов, все было включено там, где это было необходимо. Конечно, этот шаг увеличил время компиляции, но позволил мне стать более эффективным на следующем этапе.
- Я установил пробную версию ProFactors IncludeManager. Детальный просмотр проекта можно экспортировать в Excel, где узкие места и кандидаты, которые будут включены в предварительно скомпилированный заголовочный файл, можно обнаружить довольно быстро.
- Большинство времени компиляции было потрачено впустую несколькими заголовочными файлами, которые включали кучу других файлов заголовков (включая еще несколько...). Мне пришлось использовать форвардные декларации, чтобы избавиться от некоторых неприятных зависимостей. Кроме того, я переместил некоторые классы/функции из критических заголовков в свои собственные модули.
- Что помещать в предварительно скомпилированный заголовок? (MSVC) помогли мне получить входящие в предварительно скомпилированный заголовочный файл. Я добавил STL, Boost, заголовки Windows. затем добавили наши собственные (более или менее стабильные, оптимизированные) заголовки, а также заголовочный файл ресурса.
- Я повторял шаги 3 и 4 несколько раз, всегда проверяя с IncludeManager для новых кандидатов.
- Шаги с 1 по 5 привели время компиляции (режим освобождения) вниз, от 90 до 45 минут.
- Я отключил генерацию информации о просмотре для всего, поскольку мы, похоже, не используем ее (и я не мог найти никакой информации о том, на что она действительно хороша...). Это отрезало еще 6 минут процесса сборки.
- Я добавил переключатель /MP (поддержка нескольких процессоров) в команду компилятора С++. Теперь время восстановления сократилось до 22 минут. Все это было сделано на одном основном ПК.
- Я переместил все решение на двухъядерный ПК. Реконструкция проекта занимает 16 минут.
- Создание отладочной сборки на 5 минут быстрее:
- 17 минут на одноядерном компьютере,
- 11 минут на двухъядерной машине.
Обновление 2:
Выше, где я упоминаю "одноядерную машину", на самом деле подразумевается более медленная двухъядерная машина.
