Как обойти сбой компилятора Visual Studio

У нас есть большое решение Visual Studio 2005 C ++ / Mfc, 1 проект с примерно 1300 исходными файлами (то есть около 650 файлов .h и 650 .cpp). Мы также используем Boost и несколько других библиотек (COM: MSXML, Office).

Недавно я добавил несколько экземпляров boost :: multi_index, чтобы немного ускорить работу. Все это большую часть времени компилируется. Но теперь, когда я делаю полную (релизную) перестройку, у меня возникают сбои компилятора на нескольких модулях.

Fatal Error C1060: "compiler is out of heap space"

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

Странная вещь: когда я просто нажимаю F7 (сборка) после сбоя компилятора, процесс сборки продолжается без каких-либо проблем (или, по крайней мере, до следующего сбоя компилятора, где я снова нажимаю F7). Но было бы неплохо иметь возможность делать полную сборку без каких-либо перерывов.

Могу ли я повлиять на порядок сборки отдельных модулей? Таким образом, я мог бы поместить «проблемные» модули в начало процесса (и надеяться, что сбои не просто перейдут к другим модулям).

Кстати: полная сборка занимает около 90 минут.

Обновление:

Спасибо за ответы. Мне удалось избавиться от сбоев компилятора и значительно сократить время компиляции. Вот что я сделал:

1. Я удалил все включения из предварительно скомпилированного файла заголовка, только стандартные заголовки windows / mfc остались без изменений. Это заставило меня добавить еще больше включений в другие модули, но в конце концов все было включено там, где это было необходимо. Конечно, этот шаг увеличил время компиляции, но позволил мне быть более эффективным на следующем шаге.
2. Я установил пробную версию ProFactors IncludeManager. Подробное представление проекта можно экспортировать в Excel, где узкие места и кандидаты для включения в предварительно скомпилированный файл заголовка могут быть обнаружены довольно быстро.
3. Большая часть времени компиляции была потрачена на несколько файлов заголовков, которые включали в себя кучу других файлов заголовков (включая еще несколько ...). Мне пришлось использовать форвардные объявления, чтобы избавиться от некоторых неприятных зависимостей. Кроме того, я переместил некоторые классы / функции из критических заголовков в их собственные модули.
4. Что поместить в предварительно скомпилированный заголовок? (MSVC) помог мне правильно включить включение в предварительно скомпилированный файл заголовка. Я добавил заголовки STL, Boost, Windows. затем добавил наши собственные (более или менее стабильные, оптимизированные) заголовки плюс файл заголовка ресурса.
5. Я повторил шаги 3 и 4 несколько раз, всегда проверяя с помощью IncludeManager наличие новых кандидатов.
6. Шаги с 1 по 5 уменьшили время компиляции (режим выпуска) с 90 до 45 минут.
7. Я отключил создание обзорной информации для всего, так как мы, кажется, не используем ее (и я не смог найти никакой информации о том, для чего она действительно хороша ...). Это сократило процесс сборки еще на 6 минут.
8. Я добавил переключатель / MP (поддержка нескольких процессоров) в команду компилятора C ++. Теперь время восстановления сократилось до 22 минут. Все это было сделано на одноядерном ПК.
9. Я перенес все решение на двухъядерный ПК. Перестройка проекта там занимает 16 минут.
10. Creating a debug build is 5 minutes faster:
    • 17 minutes on the single core machine,
    • 11 минут на двухъядерной машине.

Обновление 2:

Выше, когда я упоминал «одноядерный компьютер», на самом деле имелся в виду более медленный двухъядерный компьютер.