Pregunta ¿Un programa compilado con -g indicador gcc es más lento que el mismo programa compilado sin -g?


Estoy compilando un programa con -O3 para el rendimiento y -g para los símbolos de depuración (en caso de falla, puedo usar el volcado del núcleo). Una cosa me molesta mucho, ¿la opción -g da como resultado una penalización de rendimiento? Cuando miro el resultado de la compilación con y sin -g, veo que la salida sin -g es 80% más pequeña que la salida de la compilación con -g. Si el espacio extra va para los símbolos de depuración, no me importa (supongo) ya que esta parte no se usa durante el tiempo de ejecución. Pero si para cada instrucción en la salida de compilación sin -g tengo que hacer 4 instrucciones más en la salida de compilación con -g que ciertamente prefiero dejar de usar la opción -g incluso a costa de no poder procesar los volcados del núcleo.

¿Cómo saber el tamaño de la sección de símbolos de depuración dentro del programa y, en general, la compilación con -g crea un programa que se ejecuta más lento que el mismo código compilado sin -g?


32
2018-06-09 09:12


origen


Respuestas:


Citando de la documentación de gcc

GCC le permite usar -g con -O. Los accesos directos tomados por optimizado   código puede ocasionalmente producir resultados sorprendentes: algunas variables   declarado puede no existir en absoluto; flujo de control puede moverse brevemente donde   no lo esperabas; algunas declaraciones no pueden ser ejecutadas porque   calculan resultados constantes o sus valores ya están a la mano;   algunas sentencias pueden ejecutarse en diferentes lugares porque han sido   movido fuera de los bucles.

eso significa:

Insertaré los símbolos de depuración pero no intentaré retenerlos si un pase de optimización los extrae, tendrá que lidiar con eso

Los símbolos de depuración no están escritos en el código sino en otra sección llamada "sección de depuración" que ni siquiera está cargada en tiempo de ejecución (solo por un depurador). Eso significa que no hay cambios de código. No debe notar ninguna diferencia de rendimiento en la velocidad de ejecución del código, pero puede experimentar cierta lentitud si el cargador necesita tratar con el binario más grande o si tiene en cuenta el aumento del tamaño del binario de alguna manera. Probablemente tendrá que comparar la aplicación usted mismo para estar 100% seguro en su caso específico.

Tenga en cuenta que también hay otra opción desde gcc 4.8:

-Og

Optimizar la experiencia de depuración. -Og habilita optimizaciones que no interfieren con la depuración. Debería ser el nivel de optimización de elección para el ciclo de edición-compilación-depuración estándar, ofreciendo un nivel razonable de optimización, manteniendo una compilación rápida y una buena experiencia de depuración.

Esta bandera será impacto en el rendimiento porque desactivará cualquier pase de optimización que pueda interferir con la depuración de información.

Finalmente, podría incluso sucede que algunas optimizaciones se adaptan mejor a una arquitectura específica en lugar de a otra y, a menos que se indique lo contrario para su procesador específico (ver marzo / mtune opciones para su arquitectura), en O3 gcc hará es lo mejor para una arquitectura genérica. Eso significa que incluso puede experimentar que O3 sea más lento que O2 en algunos escenarios artificiales. "Mejor esfuerzo" no siempre significa "el mejor disponible".


46
2018-06-09 09:17