Время компоновки GCC мало выигрывает от предварительно скомпилированных заголовков

У меня огромный проект, что-то около 150 000 LOC кода C ++. Время сборки составляет около 15 минут. Этот проект состоит из множества подпроектов разных размеров.

Я построил отдельные предварительно скомпилированные заголовки для каждого подпроекта, но при их использовании время сборки остается примерно одинаковым. Казалось, что время сборки на 5-10% процентов меньше, а не больше.

Прекомпилированные заголовки, безусловно, используются, я использую -Winvalid-pch вариант, и я попытался скомпилировать с -H Опция компилятора, мои предварительно скомпилированные заголовки появляются в выводе с символом «bang», это означает, что компилятор может использовать предварительно скомпилированный заголовок.

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

Существуют ли бесплатные / открытые инструменты для оптимизации сборки? Казалось, что стандарт make Утилита не имеет возможности измерять время сборки различных целей. Я не могу найти способ получить статистику для разных целей с make, Я не говорю об анализе зависимости или о чем-то продвинутом. Я просто хочу знать, на какие цели была потрачена большая часть времени.

Кроме того, казалось, что GCC довольно неэффективен в работе с предварительно скомпилированными заголовками. Мне не удалось получить какую-либо сборку подпроекта значительно быстрее, максимальное ускорение, которое я получаю, составляет 20% для проекта, на создание которого уходит три минуты. Казалось, что проще и дешевле купить более быструю машину с твердотельным накопителем, чем оптимизировать время сборки под Linux с GCC.

14

Решение

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

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

У меня огромный проект, что-то около 150 000 LOC кода C ++. Время сборки составляет около 15 минут. Этот проект состоит из множества подпроектов разных размеров.

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

Также рассмотрите время ссылки.

Все мои предварительно скомпилированные заголовки не очень большие, каждый файл занимает около 50 МБ.

Это довольно большой, ИМО.

Я не говорю об анализе зависимости или о чем-то продвинутом.

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

Мне не удалось получить какую-либо сборку подпроекта значительно быстрее, максимальное ускорение, которое я получаю, составляет 20%

Поймите свои структуры и зависимости. PCHs замедляют большинство моих проектов.

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

Скорее всего, эта машина не увеличит время сборки в 20 раз, но исправление ваших зависимостей и структур проекта может сделать это в 20 раз быстрее (или какой бы ни был корень проблемы в конечном итоге). Машина очень сильно помогает (учитывая время сборки 150KSLOC).

Ваша сборка, вероятно, связана с процессором / памятью.

6

Другие решения

Время компоновки GCC мало выигрывает от предварительно скомпилированных заголовков

Да, к сожалению, это часто так,

Есть несколько экспериментальных проектов, чтобы сделать что-то лучше, смотрите http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3426.html а также http://gcc.gnu.org/wiki/pph, но они еще не пригодны для использования.

Я согласен с другим ответом, что 15 минут для 150KLOC довольно медленные.

Я обнаружил, что с помощью Золото компоновщик имеет огромное значение для времени сборки, я очень рекомендую его.

Вы также можете рассмотреть CCache который может помочь, и если у вас есть запасные циклы на других машинах DistCC

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

И это, конечно, само собой разумеется, но построить на многоядерной машине и использовать make -j N где хорошее правило таково, что N должно быть в два раза больше ядер, или больше, если компиляция связана с вводом / выводом.

10

Я использую -include при генерации и использовании PCH для включения файла, который содержит много заголовков. Это помогает, но все же не так впечатляет.

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

0
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector