Поэтому я хочу распространить мое приложение GCC с ведение журнала трассировки для критических ошибок. Тем не менее, это довольно критичное к производительности приложение, поэтому мне интересно, если -g -rdynamic
Флаги gcc замедляют выполнение (особенно если они выделяют)? Также хотел бы дать моим пользователям максимальную производительность, чтобы я компилировал с флагами оптимизации, такими как "-flto"
а также "-mtune"
и это заставляет меня задаться вопросом, будут ли флаги конфликтовать, а внутри baacktrace будет безумием?
Хотя введение символов отладки само по себе не влияет на производительность, ваше приложение все еще сильно отстает в плане возможной производительности. Под этим я подразумеваю, что было бы плохо использовать -g
а также -O3
одновременно в общем. Поэтому, если ваше приложение критично к производительности, но в то же время крайне необходимо поддерживать хороший уровень отладки, было бы разумно найти некоторый баланс между этими двумя. В последних версиях GCC нам предоставляется -Og
флаг:
Оптимизировать опыт отладки.
-Og
позволяет оптимизации, которые не
мешать отладке. Это должен быть уровень оптимизации
выбор для стандартного цикла редактирования-компиляции-отладки, предлагая
разумный уровень оптимизации при сохранении быстрой компиляции
и хороший опыт отладки.
Я думаю, что было бы неплохо протестировать ваше приложение с этим флагом, чтобы увидеть, действительно ли производительность лучше, чем голая -g
, но отладка остается без изменений.
Еще раз, не пренебрегайте чтением официальной документации GCC. LTO является относительно новой функцией в GCC, и, как следствие, некоторые его части все еще являются экспериментальными и не предназначены для производства. Например, это прямая выдержка:
Оптимизация времени соединения не работает хорошо с генерацией отладки
Информация. Объединяя-flto
с-g
в настоящее время экспериментальный и
Ожидается, что даст неправильные результаты.
Не так давно у меня был смешанный опыт с LTO. Иногда это работает хорошо, иногда проект даже не компилируется, не говоря уже о том, что могут быть небольшие проблемы во время выполнения. Подводя итог всему этому, я бы не рекомендовал использовать LTO, особенно в вашей ситуации.
НОТА: Увеличение производительности от LTO обычно варьируется от 0% до 3%, и это сильно зависит от базового приложения. Без профилирования вы не сможете определить, является ли целесообразным использование LTO для вашей ситуации, поскольку это может принести больше неприятностей, чем выгод.
Флаги как -march
а также -mtune
обычно делают оптимизации на очень низком уровне — уровень обучения для целевой архитектуры процессора. Таким образом, я не ожидаю, что они будут мешать отладке. Тем не менее, вы можете сами проверить это в своем заявлении.
-g
не имеет никакого влияния на производительность. -rdynamic
увеличит размер таблицы динамических символов в основном исполняемом файле, который может быть замедлить динамическое связывание. Мое лучшее предположение состоит в том, что замедление будет очень маленьким, но, возможно, измеримым (ненулевым) с помощью точных инструментов измерения / профилирования.