Я работаю над большим проектом, большинство файлов длиннее 7000 строк.
Это довольно много.Вы можете (я не уверен) выиграть немного времени на компиляцию, избегая файлов размером более 5KLOC (путем разбиения больших файлов C ++, размером более 8KLOC на несколько) и компиляции параллельно нескольких единиц переводаодновременно (используя make -j или ninja).Это требует некоторого рефакторинга.С другой стороны, в подлинном C ++ файлы не должны быть слишком маленькими (поскольку стандартные заголовки контейнеров, такие как <vector>, могут включать в себя многие тысячи строк; вы также можете рассмотреть с предварительно скомпилированным заголовком).Практически 3KLOC - 7KLOC на исходный файл C ++ - хороший компромисс на практике.
Используйте параметр -ftime-report от до g++, чтобы получить подробные сведения о времени каждой фазы компиляции (илипроходит).Для расшифровки полученной таблицы может потребоваться понимание внутренних элементов GCC.
Я не нашел ничего о влиянии -fno-inline на производительность компиляции.Есть ли какое-либо объяснение этому?
Встроенное расширение происходит несколько раз внутри GCC.Обычно он работает на внутреннем представлении GIMPLE или SSA .Конечно, встраивание улучшает производительность вашей программы во время выполнения.Отключив его, вы можете потерять 50% скорости в вашем исполняемом файле (и, возможно, даже больше, поскольку встроенные функции-члены, такие как методы получения и установки , широко используются в C ++, особенно в стандартном контейнере шаблоны).
FWIW, мои старые GCC MELT веб-страницы (GCC MELT теперь не работает) имеют несколько слайдов и справочную информацию, объясняющую внутренние компоненты GCC, и яя сейчас пишу (октябрь 2018 года) черновик технического отчета по bismon (финансируется сейчас проектом CHARIOT H2020);что в draft есть раздел §1.2.2, объясняющий некоторые интересные оптимизации GCC.
См. также доклад CppCon 2017: Matt Godbolt «Что мой компилятор сделал для меня в последнее время?Откручивание крышки компилятора »