Как определить узкое место компиляции в большом проекте на С++?

Ответ 1

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

Ответ 2

С++ не является модульным (пока), узкие места компиляции часто связаны с проблемами; который использует слишком много файлов, когда они не нужны. Также возможно, что те, которые в настоящее время необходимы, необходимы в настоящий момент, но могут стать излишними с некоторой простой реинжинирингом.

• для обнаружения лишних включений вы можете проверить include-what-you-use, единственная проблема, с которой вы столкнетесь, заключается в том, что она работает поверх Clang, поэтому вам понадобится какая-то настройка.
• В противном случае вам необходимо просмотреть свой код и, в частности, заголовки.

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

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

Если у вас есть проблемы с пониманием того, что требуется, что нет, и как удалить лишние заголовки, я рекомендую читать Pimpls - Знаки красоты, которые вы можете зависеть На; если вы не знаете, что такое Pimpl, прочитайте Компиляция межсетевых экранов. Я бы посоветовал осторожность, хотя Pimpl имеет затраты времени на техническое обслуживание и обслуживание, поэтому используйте его только тогда, когда это действительно необходимо. Лично я бы абсолютно рекомендовал его в публичных заголовках библиотеки, которую вы доставляете сторонней стороне (совместимость с ABI), и в противном случае старайтесь ее избегать.

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

Ответ 3

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

• Храните #include охранники с каждым файлом заголовка, чтобы несколько включения не будут возникать проблемы.
• Уменьшить тело функции-члена, встроенное тело тела в файлы заголовков; просто имейте свои объявления
• Проверьте, нет ли ненужной функции и классов template; помните, что tempaltes становится inline по умолчанию. Слишком много шаблоны/метапрограммирование вызывают огромное время компиляции.
• Если число #define неоправданно высокое, то они увеличить стадию предварительной обработки, что в конечном итоге увеличивает время компиляции

Ответ 4

Вы можете заглянуть в единицы сборки.
В основном он включает все файлы .cpp в один .cpp файл и только компиляцию этого одного файла. Я тестировал его на большом проекте, и он был действительно эффективным.
Он работает из-за этого использует гораздо меньше ввода-вывода, когда он включает все ваши заголовки /cpp один раз, а не для каждого cpp.

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

Вот связанный с этим вопрос SO о Unity: #include все .cpp файлы в единый блок компиляции?