Проследите компилятор, чтобы увидеть, сколько времени он потратил на определенные файлы
Компиляция моего проекта занимает много времени, и я подумал, что хотел бы улучшить время его компиляции. Первое, что я пытаюсь сделать, это разбить время компиляции на отдельные файлы.
Так что компилятор скажет мне, например:
boost/variant.hpp: took 100ms in total
myproject/foo.hpp: took 25ms in total
myproject/bar.cpp: took 125ms in total
Затем я мог бы конкретно попытаться улучшить время компиляции файлов, занимающее больше всего времени, введя предварительное объявление и / или переупорядочив вещи, чтобы я мог опустить включаемые файлы.
Есть ли что-то для этой задачи? Я использую GCC и ICC (intel c ++)
Я использую Scons в качестве моей системы сборки.
Решение
Важным показателем является не то, сколько времени требуется для обработки (что бы это ни значило) файла заголовка, а то, как часто файл заголовка изменяется и вынуждает систему сборки повторно вызывать компилятор на всех зависимых модулях.
Время, которое компилятор тратит на разбор бесполезного кода, действительно мало по сравнению со всеми остальными этапами процесса компиляции. Даже если вы включите целые ненужные файлы, они, скорее всего, горячие в кеше диска. И предварительно скомпилированные заголовки делают это еще лучше.
Цель состоит в том, чтобы избежать перекомпиляции модулей из-за несвязанных изменений в заголовочных файлах. Вот где появляются такие методы, как pimpl и другие брандмауэры компиляции.
А генерация кода времени ссылки, иначе говоря, оптимизация всей программы, усугубляет ситуацию, отменяя брандмауэры во время компиляции и перерабатывая всю программу в любом случае.
В любом случае, информация о том, насколько нестабильным является заголовочный файл, должна быть доступна из журналов сборки, журналов фиксации и даже даты последнего изменения в файловой системе.
Другие решения
У вас есть необычное, причудливое определение времени, затраченного на обработку заголовочных файлов, которое не соответствует тому, что кто-либо еще использует. Так что вы, вероятно, можете сделать это, но вам придется сделать это самостоятельно. Наверное, лучший способ — бежать gcc под strace -tt, Затем вы можете увидеть, когда он открывает, читает и закрывает каждый файл, позволяя вам сказать, как долго он их обрабатывает.
Вы уже пробовали использовать сборку в целом? Как и любая проблема с производительностью, вполне вероятно, что то, что вы считать это проблема на самом деле не проблема. Электрическая Марка является GNU-make-совместимой реализацией make, которая может создавать аннотированный журнал сборки XML, который, в свою очередь, может использоваться для анализа проблем производительности сборки с помощью ElectricInsight. Например, отчет «Время выполнения по типу» в ElectricInsight может рассказать вам, какие действия занимают больше всего времени в вашей сборке, и, в частности, какие задания в сборке являются самыми длинными. Это поможет вам направить свои усилия в те места, где они будут наиболее плодотворными.
Например:
Отказ от ответственности: я главный архитектор Electric Make и ElectricInsight.