visual-studio - valido - visual studio code tutorial español pdf

Visual C++: Diferencia entre Inicio con/sin depuración en modo Release (4)

¿Cuál es la diferencia entre Start Debugging ( F5 ) y Start without Debugging ( CTRL - F5 ) cuando el código se compila en modo Release ?

Estoy viendo que CTRL - F5 es 10 veces más rápido que F5 para algunos códigos C ++. Si no me equivoco, el depurador se adjunta al proceso de ejecución para F5 y no es para CTRL - F5 . Como este es el modo Release, el código compilado no tiene ninguna información de depuración. Entonces, si no tengo puntos de corte, los tiempos de ejecución deberían ser los mismos en los dos, ¿no?

(Suponga que los modos Liberar y Depurar son las configuraciones típicas que obtiene cuando crea un nuevo proyecto de Visual C ++).

"Iniciar sin depurar" solo le dice a Windows que inicie la aplicación como lo haría normalmente.

"Comience con la depuración" inicia el depurador VS y ejecuta la aplicación dentro del depurador.

Esto realmente no tiene mucho que ver con la configuración de compilación de depuración / versión.

Cuando crea la configuración predeterminada de "depuración" de su aplicación, tendrá las siguientes diferencias principales con la versión de lanzamiento:

El código emitido no se optimizará, por lo que es más fácil de depurar porque se aproxima más a su fuente
El compilador y el vinculador producirán un archivo .PDB que contiene mucha información adicional para ayudar a un depurador: la presencia o ausencia de esta información no hace ninguna diferencia en el rendimiento del código, solo la facilidad de depuración.
Las macros condicionales como ASSERT y VERIFY serán operaciones no operativas en una compilación de lanzamiento, pero estarán activas en una compilación de depuración.

¡Cada uno de estos artículos es independiente y opcional! Puede activar cualquiera o todos ellos o incluso ejecutar el código debajo del depurador, simplemente no encontrará la vida tan fácil.

Cuando ejecuta ''con depuración'' las cosas funcionan de manera diferente por varias razones:

El depurador VS es muy ineficaz al iniciarse, en parte porque todo en VS es lento: en las versiones anteriores a VS2010, cada píxel de la pantalla se volverá a pintar unas 30 veces a medida que el IDE se tambalea en el modo de depuración con mucha intermitencia y parpadeo.
Dependiendo de cómo se configuran las cosas, el depurador puede pasar mucho tiempo al inicio tratando de cargar símbolos (es decir, archivos PDB) para muchos componentes del sistema operativo que son parte de su proceso, puede intentar obtener estos archivos en la web, que puede tomar una edad en algunas circunstancias.
Una serie de actividades que normalmente realiza su aplicación (cargar DLL, iniciar subprocesos, manejar excepciones) hacen que se le avise al depurador. Esto tiene el efecto tanto de ralentizarlos como de hacer que tiendan a ejecutarse secuencialmente.

Cuando se ejecuta ''con depuración'', se usa el montón de depuración, incluso para el modo de lanzamiento. Esto causa ralentizaciones severas en el código utilizando una gran cantidad de malloc / free o new / delete, lo que puede suceder en el código C ++ sin que te des cuenta porque las bibliotecas / clases tienden a ocultar esta gestión de memoria.

El problema es que Windows incluye un Depósito de depuración especial, si detecta que su programa se está ejecutando bajo un Depurador. Esto parece ocurrir en el nivel del sistema operativo, y es independiente de las configuraciones del modo de depuración / liberación para su compilación.

Puede solucionar esta "característica" configurando una variable de entorno: _NO_DEBUG_HEAP = 1

Este mismo problema me ha estado volviendo loco por un tiempo; hoy encontré lo siguiente, de donde se deriva esta publicación: http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx

IsDebuggerPresent() y OutputDebugString() comportan de manera diferente dependiendo de si se ha conectado un depurador.

IsDebuggerPresent() simplemente devuelve otro valor, por lo que su programa puede reaccionar a este valor y comportarse de manera diferente a propósito. OutputDebugString() regresa mucho más rápido cuando no hay un depurador conectado, por lo que si se llama muchas veces, verá que el programa se ejecuta mucho más rápido sin el depurador.