Как мне найти, какие части кода занимают много времени для компиляции?
Я уже использую предварительно скомпилированные заголовки для всех моих заголовков, и они определенно улучшают скорость компиляции. Тем не менее, когда бы я ни вносил изменения в мой исходный файл C ++, его компиляция занимает много времени (это связано с CPU / памятью, не I / O-привязано - все это кэшируется). Кроме того, это не относится к части связывания, только к части компиляции.
Я пытался включить /showIncludes, но, конечно, поскольку я использую предварительно скомпилированные заголовки, после stdafx.h ничего не включается. Так что я знаю, что для компиляции требуется только исходный код, но я не знаю, какая его часть.
Я также пытался сделать минимальную сборку, но это не помогает. Ни один не делает /MP, потому что это все равно один исходный файл.
Я мог бы попытаться разобрать исходный код и выяснить, какая часть является узким местом, добавляя / удаляя его, но это боль и не масштабируется. Кроме того, трудно что-то удалить и все же позволить скомпилировать код - сообщения об ошибках, если таковые имеются, возвращаются почти немедленно.
Есть ли лучший способ выяснить, что замедляет компиляцию?
Или, если нет способа: существуют ли языковые конструкции (например, шаблоны?), Которые компилируются намного дольше?
Что у меня есть в исходном коде C ++:
Три (относительно больших) диалоговых класса ATL (включая определения / логику).
Они вполне могут быть причиной, но они в любом случае являются основной частью программы, поэтому, очевидно, им нужно перекомпилировать всякий раз, когда я их изменяю.
Случайные однострочные (или аналогично малые) вспомогательные функции, например, преобразователь байтового массива в шестнадцатеричный
Ссылки на (встроенные) классы, найденные в моих заголовочных файлах. (Один из заголовочных файлов гигантский, но он использует шаблоны только минимально, и, конечно, он предварительно скомпилирован. Другой - TR1 regex - он огромный, но почти не используется.)
Примечание:
Я ищу техник , которые я могу применять более широко при выяснении причины этих проблем, не конкретных рекомендаций для моей конкретной ситуации. Надеюсь, это было бы более полезным для других людей.