Я не знаю о существующем инструменте для этого, но я бы предложил:
Во-первых, измерьте стоимость отдельного включения каждого заголовка. Составьте список всех заголовков и предварительно обработайте каждый заголовок. Простейшей мерой стоимости этого заголовка является количество строк, полученных в результате предварительной обработки. Возможно, более точной мерой было бы подсчет вхождений «шаблона», поскольку, по моему опыту, обработка определений шаблона, по моему опыту, доминирует над временем компиляции. Вы также можете подсчитать количество вхождений 'inline', поскольку я видел, что большое количество встроенных функций, определенных в заголовках, также является проблемой (но имейте в виду, что встроенные определения методов класса не обязательно используют ключевое слово).
Затем измерьте количество единиц перевода (ЕП), содержащих этот заголовок. Для каждого основного файла TU (например, файла .cpp) предварительно обработайте этот файл и соберите набор отдельных заголовков, которые появляются в выходных данных (в строках #). После этого инвертируйте это, чтобы получить карту из заголовка в количество TU, которые его используют.
Наконец, для каждого заголовка умножьте его отдельную стоимость на количество TU, которые его включают. Это мера совокупного влияния этого заголовка на общее время компиляции. Отсортируйте этот список и просмотрите его в порядке убывания, перемещая частные детали реализации в связанный файл реализации и соответствующим образом обрезая публичный заголовок.
Теперь основная проблема с этим или любым подобным подходом к измерению преимуществ частных реализаций заключается в том, что вы, вероятно, не увидите больших изменений поначалу, потому что при отсутствии инженерной дисциплины, чтобы сделать иначе, обычно будет много заголовков, которые включают много другие, с большим количеством совпадений. Следовательно, оптимизация одного интенсивно используемого заголовка будет просто означать, что какой-то другой интенсивно используемый заголовок, который включает почти столько же, будет поддерживать высокое время компиляции. Но как только вы преодолеете критическую массу широко используемых заголовков, которые имеют много зависимостей, оптимизируя большинство или все из них, время компиляции должно начать резко сокращаться.
Один из способов сосредоточить усилия, чтобы это не было "журавлем в небе", состоит в том, чтобы начать с выбора единственной TU, компиляция которой занимает больше всего времени, и работать над оптимизацией только тех заголовков, от которых она зависит. После того, как вы значительно сократите время для этого TU, снова взгляните на общую картину. И если вы не можете значительно улучшить время компиляции этого одного TU с помощью метода частной реализации, то это означает, что вам нужно рассмотреть другие подходы для этой кодовой базы.
person
Scott McPeak
schedule
15.03.2020
