Является ли программа, скомпилированная с -g gcc флагом медленнее той же самой программы, скомпилированной без -g?

Я компилирую программу с -O3 для производительности и -g для отладочных символов (в случае сбоя я могу использовать дамп ядра). Меня что-то беспокоит, делает ли параметр -g штрафом за производительность? Когда я смотрю на результат компиляции с и без -g, я вижу, что выход без -g на 80% меньше результата компиляции с -g. Если дополнительное пространство для символов отладки, я не забочусь об этом (я думаю), так как эта часть не используется во время выполнения. Но если для каждой команды в выводе компиляции без -g мне нужно сделать еще 4 команды в выводе компиляции с -g, чем я, конечно, предпочитаю прекратить использование опции -g даже за счет того, что вы не можете обрабатывать дампы ядра.

Как узнать размер раздела символов отладки внутри программы и вообще компиляция с -g создает программу, которая работает медленнее, чем тот же код, скомпилированный без -g?

Ответ 1

Цитирование из документации gcc

GCC позволяет использовать -g с -O. Ярлыки, сделанные оптимизированными код может иногда приводить к неожиданным результатам: некоторые переменные вы объявленные могут вообще не существовать; поток управления может ненадолго перемещаться туда вы этого не ожидали; некоторые операторы могут не выполняться, потому что они вычисляют постоянные результаты или их значения уже под рукой; некоторые заявления могут выполняться в разных местах, поскольку они были выведенный из циклов.

это означает:

Я буду вставлять в нее отладочные символы, но я не буду пытаться их сохранить, если прогон оптимизации закроет их, вам придется иметь дело с этим

Отладочные символы не записываются в код, а в другой раздел под названием "раздел отладки", который даже не загружается во время выполнения (только отладчиком). Это означает: никаких изменений кода не происходит. Вы не должны замечать разницу в скорости выполнения кода, но вы можете столкнуться с некоторой медлительностью, если загрузчик должен иметь дело с большим двоичным кодом или если он каким-то образом учитывает увеличенный размер двоичного кода. Вам, вероятно, придется ориентироваться на приложение самостоятельно, чтобы быть уверенным на 100% в вашем конкретном случае.

Обратите внимание, что там также другой вариант из gcc 4.8:

-Og

Оптимизируйте опыт отладки. -Og включает оптимизацию, которая не мешает отладке. Это должен быть оптимальный уровень выбора для стандартного цикла редактирования-компиляции-отладки, предлагающий разумный уровень оптимизации при сохранении быстрой компиляции и хорошей отладочной работе.

Этот флаг будет влиять на производительность, поскольку он отключит любой шаг оптимизации, который будет мешать информации об отладке.

Наконец, может показаться даже, что некоторые оптимизации лучше подходят для конкретной архитектуры, а не для другой, и если это не будет указано для вашего конкретного процессора (см. march/mtune для вашей архитектуры), в O3 gcc сделает лучшим для общей архитектуры. Это означает, что вы, возможно, даже испытываете O3 медленнее, чем O2 в некоторых надуманных сценариях. "Лучшее усилие" не всегда означает "лучший доступный".