Какие методы можно использовать для ускорения компиляции C++?

Я имел представление о с использованием RAM-диска. Оказалось, что для моих проектов это не имеет большого значения. Но тогда они еще довольно маленькие. Попытайся! Мне было бы интересно услышать, насколько это помогло.

Если у вас многоядерный процессор, Visual Studio (2005 и новее), а также GCC поддерживают многопроцессорные компиляции. Это то, что нужно включить, если у вас есть оборудование.

Я просто сделаю ссылку на свой другой ответ: Как ВЫ сокращаете время компиляции и время компоновки для проектов Visual C++ (собственный C++)?. Еще один момент, который я хочу добавить, но который часто вызывает проблемы, - это использование предварительно скомпилированных заголовков. Но, пожалуйста, используйте их только для частей, которые почти никогда не меняются (например, заголовки GUI toolkit). В противном случае они будут стоить вам больше времени, чем в конечном итоге сэкономят.

Другой вариант - при работе с GNU make включить опцию -j<N>:

  -j [N], --jobs[=N]          Allow N jobs at once; infinite jobs with no arg.

Обычно он у меня на 3, так как здесь у меня двухъядерный. Затем он будет запускать компиляторы параллельно для разных единиц перевода при условии, что между ними нет зависимостей. Связывание нельзя выполнять параллельно, поскольку существует только один процесс компоновщика, связывающий вместе все объектные файлы.

Но сам компоновщик может быть многопоточным, и именно это делает компоновщик GNU goldELF. Это оптимизированный многопоточный код C++, который, как говорят, связывает объектные файлы ELF намного быстрее, чем старый ld (и фактически был включен в binutils).

Вот некоторые:

• Используйте все ядра процессора, запустив задание множественной компиляции (make -j2 - хороший пример).
• Отключите или уменьшите оптимизацию (например, GCC намного быстрее с -O1, чем -O2 или -O3).
• Используйте предварительно скомпилированные заголовки.

• Обновите свой компьютер

  1. Получите четырехъядерный процессор (или двухкамерную систему)
  2. Получите МНОГО ОЗУ.
  3. Используйте RAM-диск, чтобы значительно сократить задержки файлового ввода-вывода. (Есть компании, которые делают диски IDE и SATA RAM, которые действуют как жесткие диски).

• Тогда у вас есть все другие типичные предложения

  1. Если возможно, используйте предварительно скомпилированные заголовки.
  2. Уменьшите количество взаимосвязей между частями вашего проекта. Изменение одного файла заголовка обычно не требует перекомпиляции всего проекта.

Использовать

#pragma once

в верхней части файлов заголовков, поэтому, если они включены в единицу перевода более одного раза, текст заголовка будет включен и проанализирован только один раз.

Когда я закончил колледж, первый настоящий производственный код на C++, который я увидел, содержал эти загадочные директивы #ifndef ... #endif между ними, где были определены заголовки. Я очень наивно спросил парня, который писал код, об этих всеобъемлющих вещах, и меня познакомили с миром крупномасштабного программирования.

Возвращаясь к сути, использование директив для предотвращения дублирования определений заголовков было первым, что я узнал, когда дело дошло до сокращения времени компиляции.

Языковые техники

Pimpl Idiom

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

Предварительные декларации

По возможности используйте предварительные декларации. Если компилятору нужно только знать, что SomeIdentifier - это структура, указатель или что-то еще, не включайте определение целиком, заставляя компилятор выполнять больше работы, чем нужно. Это может иметь каскадный эффект, делая этот способ медленнее, чем нужно.

Потоки Ввод / вывод особенно известны тем, что замедляют сборку. Если они вам нужны в файле заголовка, попробуйте # включить <iosfwd> вместо <iostream> и # включить заголовок <iostream> только в файл реализации. Заголовок <iosfwd> содержит только предварительные объявления. К сожалению, другие стандартные заголовки не имеют соответствующего заголовка объявлений.

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

Условия охраны

Используйте защитные условия, чтобы файлы заголовков не включались более одного раза в одну единицу перевода.

#pragma once
#ifndef filename_h
#define filename_h

// Header declarations / definitions

#endif

Используя как прагму, так и ifndef, вы получаете переносимость простого макрорешения, а также оптимизацию скорости компиляции, которую некоторые компиляторы могут выполнять при наличии директивы pragma once.

Уменьшить взаимозависимость

Чем в целом более модульный и менее взаимозависимый дизайн вашего кода, тем реже вам придется все перекомпилировать. Вы также можете сократить объем работы, которую компилятор должен выполнять одновременно с любым отдельным блоком, в силу того, что ему нужно меньше отслеживать.

Параметры компилятора

Предварительно скомпилированные заголовки

Они используются для компиляции общего раздела включаемых заголовков один раз для многих единиц перевода. Компилятор компилирует его один раз и сохраняет его внутреннее состояние. Затем это состояние можно быстро загрузить, чтобы получить преимущество при компиляции другого файла с тем же набором заголовков.

Будьте осторожны и не включайте в предварительно скомпилированные заголовки редко изменяемые данные, иначе вы можете выполнять полную перестройку чаще, чем это необходимо. Это хорошее место для заголовков STL и других включаемых файлов библиотеки.

ccache - еще одна утилита, которая использует преимущества методов кэширования для ускорения работы.

Использовать параллелизм

Многие компиляторы / IDE поддерживают использование нескольких ядер / процессоров для одновременной компиляции. В GNU Make (обычно используется с GCC) используйте опцию -j [N]. В Visual Studio в настройках есть опция, позволяющая создавать несколько проектов параллельно. Вы также можете использовать /MP вариант для параллелизма на уровне файлов, а не только для параллелизма на уровне проекта.

Другие параллельные утилиты:

• Incredibuild
• Сборка Unity
• distcc

Используйте более низкий уровень оптимизации

Чем больше компилятор пытается оптимизировать, тем тяжелее ему приходится работать.

Общие библиотеки

Перенос менее часто изменяемого кода в библиотеки может сократить время компиляции. Используя совместно используемые библиотеки (.so или .dll), вы также можете сократить время компоновки.

Получите более быстрый компьютер

Больше оперативной памяти, более быстрые жесткие диски (включая твердотельные накопители) и большее количество процессоров / ядер повлияют на скорость компиляции.

По возможности используйте форвардные объявления. Если в объявлении класса используется только указатель или ссылка на тип, вы можете просто объявить его вперед и включить заголовок для типа в файл реализации.

Например:

// T.h
class Class2; // Forward declaration

class T {
public:
    void doSomething(Class2 &c2);
private:
    Class2 *m_Class2Ptr;
};

// T.cpp
#include "Class2.h"
void Class2::doSomething(Class2 &c2) {
    // Whatever you want here
}

Меньшее количество включений означает гораздо меньше работы для препроцессора, если вы сделаете это достаточно.

Я бы порекомендовал эти статьи из "Игры изнутри, инди-дизайн игр и программирование":

• Физическая структура и C++ - Часть 1: Первый взгляд
• Физическая структура и C++ - Часть 2: Время сборки
• Еще больше экспериментов с включениями
• Насколько невероятна «Incredibuild»?
• Уход за предварительно скомпилированными заголовками и их кормление
• В поисках идеальной системы сборки
• В поисках идеальной системы сборки (часть 2)

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

Вы можете использовать Сборки Unity.

Взаимодействие с другими людьми

Просто для полноты: сборка может быть медленной из-за глупости системы сборки, а также из-за того, что компилятор долго выполняет свою работу.

Прочтите Рекурсивное объявление считается вредным (PDF) для обсуждения этой темы в средах Unix.

Где ты проводишь время? Вы привязаны к процессору? Ограничена память? Диск связан? Можно еще ядер использовать? Больше оперативной памяти? Вам нужен RAID? Вы просто хотите повысить эффективность своей нынешней системы?

Под gcc / g ++ вы смотрели ccache? Это может быть полезно, если вы много занимаетесь make clean; make.

После того, как вы применили все описанные выше приемы кода (предварительные объявления, сокращение включения заголовков до минимума в общедоступных заголовках, размещение большей части деталей внутри файла реализации с помощью Сутенер ...) и больше ничего не может быть получено с точки зрения языка, рассмотрите свою систему сборки . Если вы используете Linux, рассмотрите возможность использования distcc (распределенный компилятор) и ccache (компилятор кеша).

Первый, distcc, выполняет шаг препроцессора локально, а затем отправляет выходные данные первому доступному компилятору в сети. Для этого требуются одинаковые версии компилятора и библиотеки на всех настроенных узлах сети.

Последний, ccache, представляет собой кеш компилятора. Он снова запускает препроцессор, а затем проверяет внутреннюю базу данных (хранящуюся в локальном каталоге), если этот файл препроцессора уже был скомпилирован с теми же параметрами компилятора. Если это так, он просто выводит двоичный файл и выводит его при первом запуске компилятора.

Оба могут использоваться одновременно, так что, если ccache не имеет локальной копии, он может отправить ее по сети на другой узел с помощью distcc, иначе он может просто внедрить решение без дальнейшей обработки.

Динамическое связывание (.so) может быть намного быстрее, чем статическое связывание (.a). Особенно если у вас медленный сетевой диск. Это потому, что у вас есть весь код в файле .a, который необходимо обработать и записать. Кроме того, на диск необходимо записать исполняемый файл гораздо большего размера.

Больше оперативной памяти.

Кто-то говорил о накопителях RAM в другом ответе. Я сделал это с 80286 и Турбо C++ (показывает возраст), и результаты были феноменальными. Как и потеря данных, когда машина разбилась.

По этой теме есть целая книга под названием Разработка крупномасштабного программного обеспечения на C++ (написанная Джоном Лакосом).

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

В Linux (и, возможно, в некоторых других * NIX) вы действительно можете ускорить компиляцию, НЕ СМОТРЕТЬ на выходе и переключившись на Другой TTY.

Вот эксперимент: printf замедляет мою программу

Один из приемов, который в прошлом работал у меня довольно хорошо: не компилируйте несколько исходных файлов C++ независимо, а лучше сгенерируйте один файл C++, который включает в себя все остальные файлы, например:

// myproject_all.cpp
// Automatically generated file - don't edit this by hand!
#include "main.cpp"
#include "mainwindow.cpp"
#include "filterdialog.cpp"
#include "database.cpp"

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

Эта техника ломается в различных случаях; например, компилятор выйдет из строя, если два или более исходных файла объявят глобальную функцию с тем же именем. Я не смог найти эту технику, описанную ни в одном из других ответов, поэтому я упоминаю ее здесь.

Как бы то ни было, Проект KDE использовал ту же самую технику с 1999 года для создания оптимизированных двоичных файлов (возможно, для выпуска). Переключение на сценарий настройки сборки называлось --enable-final. Из археологических интересов я откопал сообщение, в котором сообщалось об этой функции: http://lists.kde.org/?l=kde-devel&m=92722836009368&w=2

Хотя это и не была «техника», я не мог понять, как проекты Win32 с большим количеством исходных файлов компилируются быстрее, чем мой пустой проект «Hello World». Таким образом, я надеюсь, что это поможет кому-то так же, как я.

В Visual Studio одним из вариантов увеличения времени компиляции является добавочное связывание (/ ДОПОЛНИТЕЛЬНЫЙ). Это несовместимо с генерацией кода во время компоновки (/ LTCG), поэтому не забудьте отключить инкрементное связывание при выполнении сборок выпуска.

Более быстрые жесткие диски.

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

Общие сетевые ресурсы резко замедлят вашу сборку, так как задержка поиска высока. Для чего-то вроде Boost это имело огромное значение для меня, хотя наш сетевой диск довольно быстрый. Когда я переключился с общего сетевого ресурса на локальный SSD, время на компиляцию игрушечной программы Boost уменьшилось с 1 минуты до 1 секунды.

Не о времени компиляции, а о времени сборки:

• Используйте ccache, если вам нужно пересобрать те же файлы во время работы. в ваших файлах сборки

• Используйте ниндзя-билд вместо make. Я сейчас составляю проект с ~ 100 исходными файлами, и все кэшируется ccache. делать нужды 5 минут, ниндзя меньше 1.

Вы можете сгенерировать свои файлы ниндзя из cmake с помощью -GNinja.

Начиная с Visual Studio 2017 у вас есть возможность получать некоторые метрики компилятора о том, что требует времени.

Добавьте эти параметры в C / C++ -> Командная строка (Дополнительные параметры) в окне свойств проекта: /Bt+ /d2cgsummary /d1reportTime

Вы можете получить дополнительную информацию в этом посте.

Использование динамической компоновки вместо статической делает ваш компилятор более быстрым.

Если вы используете t Cmake, активируйте свойство:

set(BUILD_SHARED_LIBS ON)

Build Release, используя статическое связывание, можно оптимизировать.

Прежде всего, мы должны понять, что такого особенного в C++, что отличает его от других языков.

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

Некоторые говорят, что важен размер файла. Нет, строки исходного кода не коррелируют со временем компиляции.

Но подождите, как это может быть? Больше строк кода должно означать более длительное время компиляции, в чем волшебство?

Хитрость в том, что в директивах препроцессора скрыто множество строк кода. Да. Всего один #include может испортить производительность компиляции вашего модуля.

Видите ли, в C++ нет модульной системы. Все файлы *.cpp скомпилированы с нуля. Таким образом, наличие 1000 файлов * .cpp означает тысячу компиляций вашего проекта. У вас есть больше? Печалька.

Вот почему разработчики C++ не решаются разбивать классы на несколько файлов. Все эти заголовки утомительно поддерживать.

Итак, что мы можем сделать, кроме использования предварительно скомпилированных заголовков, объединения всех файлов cpp в один и сохранения минимального количества заголовков?

C++ 20 предоставляет нам предварительную поддержку модули! В конце концов, вы сможете забыть о #include и ужасной производительности компиляции, которую приносят с собой файлы заголовков. Тронули один файл? Перекомпилируйте только этот файл! Нужно создать новую кассу? Компилируйте за секунды, а не за минуты и часы.

Сообщество C++ должно как можно скорее перейти на C++ 20. Разработчики компиляторов C++ должны уделять этому больше внимания, разработчики C++ должны начать тестирование предварительной поддержки в различных компиляторах и использовать те компиляторы, которые поддерживают модули. Это самый важный момент в истории C++!