Как ВЫ сокращаете время компиляции и связывания времени для проектов Visual C ++ (нативный C ++)?

Question

Как ВЫ сокращаете время компиляции и время компоновки для проектов VC ++ (нативный C ++)?

Укажите, относится ли каждое предложение к отладке, выпуску или к обоим.

Answer 1

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

// Forward declaration stuff
namespace plotter { namespace logic { class Plotter; } }

// Real stuff
namespace plotter {
    namespace samples {
        class Window {
            logic::Plotter * mPlotter;
            // ...
        };
    }
}

Это значительно сокращает время компиляции и на других компиляторах. На самом деле это относится ко всем конфигурациям:)

Answer 2

Используйте шаблон Handle / Body (также известный как «pimpl», «adapter», «decorator», «bridge» или «wrapper»). Изолировав реализацию ваших классов в ваших .cpp файлах, их нужно скомпилировать только один раз. Для большинства изменений не требуется вносить изменения в заголовочный файл, так что это означает, что вы можете вносить довольно обширные изменения, требуя перекомпиляции только одного файла. Это также способствует рефакторингу и написанию комментариев и модульных тестов, так как время компиляции уменьшается. Кроме того, вы автоматически разделяете проблемы интерфейса и реализации, чтобы интерфейс вашего кода был упрощен.

Answer 3

Если у вас большие сложные заголовки, которые должны включаться в большинство файлов .cpp в процессе сборки и которые не очень часто меняются, вы можете предварительно скомпилировать их. В проекте Visual C ++ с типичной конфигурацией это просто вопрос включения их в stdafx.h. У этой функции есть свои недостатки, но библиотеки, которые в полной мере используют шаблоны, как правило, содержат много материала в заголовках, и предварительно скомпилированные заголовки - самый простой способ ускорить сборку в этом случае.

Answer 4

Я использую Unity Builds (Скриншот , расположенный здесь ).

Answer 5

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

Форвардные декларации являются распространенным решением.

Распределенное здание, например, Incredibuild, является победой.

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

Решение, о котором я не читал, но которое использовал, заключается в разделении больших заголовков. Если у вас есть несколько очень больших заголовков, взгляните на них. Они могут содержать связанную информацию, а также могут зависеть от множества других заголовков. Возьмите элементы, которые не зависят от других файлов ... простые структуры, константы, перечисления и предварительные объявления и переместите их с the_world.h на the_world_defs.h. Теперь вы можете обнаружить, что многие из ваших исходных файлов теперь могут включать только the_world_defs.h и избегать включения всех этих накладных расходов.

Visual Studio также имеет параметр «Показать включения», который позволяет определить, какие исходные файлы содержат много заголовков, а какие файлы заголовков включены чаще всего.

Для очень распространенных включений рассмотрите возможность помещения их в предварительно скомпилированный заголовок.

Answer 6

Вопрос о скорости компиляции достаточно интересен, и у Страуструпа он есть в его FAQ .

Answer 7

Мы используем Xoreax Incredibuild для параллельного запуска компиляции на нескольких машинах.

Answer 8

Также интересная статья от Неда Батчелдера: http://nedbatchelder.com/blog/200401/speeding_c_links.html (о C ++ в Windows).

Answer 9

Наши машины для разработки являются четырехъядерными, и мы используем Visual Studio 2008 с поддержкой параллельной компиляции. Я не уверен, могут ли все выпуски VS сделать это.

У нас есть файл решения, включающий примерно 168 отдельных проектов, и его компиляция занимает около 25 минут на наших четырехъядерных компьютерах по сравнению с примерно 90 минутами на одноядерных ноутбуках, которые мы даем летним студентам. Не совсем сопоставимые машины, но вы поняли:)

Answer 10

В Visual C ++ существует метод, который некоторые называют Unity, который значительно улучшает время соединения за счет уменьшения количества объектных модулей.

Это включает в себя конкатенацию кода C ++, обычно в группах по библиотекам. Это, конечно, делает редактирование кода намного более сложным, и вы столкнетесь с коллизиями пространства имен, если не будете их правильно использовать. Он не позволяет использовать "using namespace foo";

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