Я создаю много автоматически сгенерированного кода, включая один особенно большой файл (~ 15K строк), используя кросс-компилятор mingw32 на linux. Большинство файлов очень быстрые, но этот один большой файл занимает неожиданно много времени (~ 15 минут) для компиляции.
Я пытался манипулировать различными флагами оптимизации, чтобы увидеть, оказали ли они какое-либо влияние, без какой-либо удачи. Что мне действительно нужно, так это какой-то способ определения того, что делает g ++, который занимает так много времени. Есть ли какие-либо (относительно простые) способы, чтобы g ++ генерировал вывод о разных фазах компиляции, чтобы помочь мне сузить круг возможных зависаний?
К сожалению, у меня нет возможности перестроить этот кросс-компилятор, поэтому добавить отладочную информацию в компилятор и пройти через нее невозможно.
Что в файле:
- куча включает
- куча сравнений строк
- куча проверок if-then и вызовов конструктора
Файл представляет собой фабрику для производства тонны различных специфических подклассов определенного родительского класса. Большинство включений, однако, ничего необычного.
Результаты отчета -ftime-report, предложенные Нилом Баттервортом, показывают, что фаза «анализа жизни» занимает 921 секунду, что занимает большую часть 15 минут.
Похоже, что это происходит во время анализа потока данных. Сам файл представляет собой набор условных сравнений строк, создающих объект по имени класса, предоставленному в виде строки.
Мы думаем, что изменение этого положения на карту имен для указателей на функции может немного улучшить ситуацию, поэтому мы попробуем это.
Действительно, создание набора фабричных функций (для каждого объекта) и создание карты от строкового имени объекта до указателя на его фабричную функцию сократило время компиляции с исходных 15 минут до примерно 25 секунд, что спасет всех тонны времени на их сборку.
Еще раз спасибо Нилу Баттеруорту за подсказку о -ftime-report.