Каковы плюсы и минусы предварительно скомпилированных заголовков, особенно в среде / цепочке инструментов среды GNU / Linux?

Question

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

Каковы плюсы и минусы использования предварительно скомпилированных заголовков, и, в частности, их использование в среде Gnu / gcc / Linux?

Answer 1

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

• Больше зависимостей Makefile, чтобы получить право; если они не правы, вы быстро строите неправильные вещи. Не хорошо.

• В принципе, не каждый заголовок может быть предварительно скомпилирован. (Подумайте о том, чтобы поместить # define перед #include.) Итак, в каких случаях gcc на самом деле справляется? Насколько вы хотите доверять этой передовой функции.

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

• Покупка более быстрого оборудования, которое дешевле по сравнению с зарплатой

• Использование таких инструментов, как AT & T nmake или подобных ccache (Дирк прав), оба из которых используют надежные методы, чтобы избежать перекомпиляций.

Answer 2

Я не могу общаться с GNU / gcc / linux, но я имел дело с предварительно скомпилированными заголовками в vs2005:

Плюсы:

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

Минусы:

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

Answer 3

Интерфейс кэширования ccache для gcc, g ++, gfortran, ... прекрасно работает для меня. Как говорится на его сайте

ccache - кеш компилятора. Действует как препроцессор кеширования на C / C ++ компиляторы, использующие компилятор -E переключатель и хэш, чтобы обнаружить, когда компиляция может быть удовлетворена от кэш. Это часто приводит к 5 до 10 ускорение в обычных сборниках.

В Debian / Ubuntu, просто выполните 'apt-get install ccache' и создайте программные ссылки, скажем, /usr/local/bin с именами gcc, g++, gfortran, c++, ... этой точки до /usr/bin/ccache.

[ EDIT ] Чтобы сделать это более явным в ответ на некоторые ранние комментарии: Это обеспечивает по существу предварительно скомпилированные заголовки и источники путем кэширования большей части шага компиляции. Таким образом, он использует идею, которая похожа на предварительно скомпилированные заголовки, и продвигает ее дальше. Ускорения могут быть значительными - в 5-10 раз, как говорится на сайте.

Answer 4

В документации GNU gcc обсуждаются возможные подводные камни с предварительно скомпилированными заголовками.

Answer 5

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

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

Answer 6

Я использую PCH в проекте Qt, который использует cmake в качестве системы сборки, и это экономит много времени. Я взял несколько сценариев PCH cmake, которые нуждались в доработке, поскольку они были довольно старыми, но в целом их было проще настроить, чем я ожидал. Я должен добавить, я не большой эксперт по Cmake.

Теперь я включаю большую часть Qt (QtCore, QtGui, QtOpenGL) и несколько стабильных заголовков одновременно.

Плюсы:

• Для классов Qt предварительные объявления не требуются и, конечно, не включают.
• быстро.
• Простота настройки.

Минусы:

• Вы не можете включать PCH в заголовки. Это не большая проблема, за исключением того, что вы используете Qt и позволяете системе сборки отдельно переводить moc-файлы, что в точности соответствует моей конфигурации. В этом случае вам нужно #include заголовки qt в ваших заголовках, потому что mocs генерируются из заголовков. Решение заключалось в том, чтобы добавить дополнительные заголовки вокруг #include в заголовке.