Tengo un nativo de C++ programa que se ejecuta en más de 20 veces más lento cuando se inicia con de Depuración (F5), pero funciona a velocidad normal cuando se utiliza iniciar sin depurar (Ctrl + F5).

No importa si yo uso un debug o release. También si puedo usar WinDbg el programa es de una magnitud más lento.

¿Hay alguna opción de configuración que me hizo elegir mal o algo?

  • Depuración añade un montón de sobrecarga para un programa. ¿Por qué estás suponiendo cosas están mal?
  • Depuración no debe añadir un montón de sobrecarga. La diferencia entre un depurador conectado y no conectado no debe ser una diferencia en absoluto.
InformationsquelleAutor plaisthos | 2010-07-29

7 Comentarios

  1. 16

    Conjunto de la _NO_DEBUG_HEAP variable de entorno a 1 (como se ve en http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger).

    Esto se puede hacer desde dentro de Visual Studio, también.

    Ahora esto es sólo una solución temporal, y tengo la curiosidad de saber cómo refactorizar un programa que sufre de este tipo de problema. Tienes muchos std::map, shared_ptr, o cualquier otra gran indirections por casualidad?

    • No puedo confirmar si este es realmente el caso en mi programa, pero realmente suena como mi problema.
  2. 12

    Supuesto, esto no es causado por el _DEBUG símbolo definido o compilar el código en la configuración de depuración. El agregado de depuración de código se ejecuta si es o no el depurador se adjunta el programa.

    El depurador no suelen afectar a la ejecución de código, se queda fuera de la manera de llamar a WaitForDebugEvent. Que lo bloquea hasta que el sistema operativo le dice que algo digno de mención ocurrió. Que puede desencadenar un montón de código en el depurador que puede ralentizar su programa. Usted puede ver los eventos enumerados en la DEBUG_EVENT documentación de la estructura.

    Proveyéndolos un poco más allá de la documentación: el depurador pasos y puede ralentizar su programa cuando:

    • El programa se carga o descarga un archivo DLL. Muchas de las cosas que ocurre durante la carga, el depurador va a la caza de un archivo de símbolos de depuración (.pdb). Puede contactar a un servidor de símbolos para descargarlo. Los puntos de interrupción que se establecieron en la DLL de código fuente será activada. Esto puede ser bastante lento, pero el efecto es temporal y por lo general sólo ralentiza el inicio. Usted puede ver la carga/descarga de notificación en la ventana de Salida.

    • El programa plantea una excepción. Esto activa el depurador en el momento en que la excepción se produce, una «primera oportunidad de la notificación». Que puede ser muy útil, puede utilizar la Depuración + de Excepción, Lanzado casilla de verificación para hacer que el depurador se detiene cuando la excepción se produce. Usted puede ver el mensaje de notificación en la ventana de Salida. Este hace ralentizar el código que plantea y las capturas excepciones enormemente y es muy probable que la fuente de su desaceleración. Nunca utilizar excepciones para el control de flujo.

    • Un hilo comienza a correr o se cancela. De nuevo, un mensaje de notificación se imprime en la ventana de Salida. Tendrías que crear un mucho de hilos para hacer de este ralentizar su programa.

    • Cuando se utiliza el programa OutputDebugString() para fines de seguimiento. Visible en la ventana de Salida. Otro buen candidato para una desaceleración, la producción cae en el bit bucket si no depurador se adjunta. Usted no debería tener ningún problema para el diagnóstico de esta entidad como la causa, el obvio efecto secundario es la de ver a un mucho de mensajes en la ventana de Salida.

    • Cuando el programa llega un punto de interrupción. No un montón de razones para estar perplejo por que uno. Pero usted puede establecer puntos de interrupción que ralentizar el programa un montón de no causar una interrupción del depurador. En particular, el punto de interrupción Condicional, contador de visitas, el Filtro y el momento de Golpear la operación será lenta. El uso de Depuración + Windows + puntos de corte para revisar los puntos de corte definidos.

    • El uso de Prisma aquí, así que carga una gran cantidad de módulos después de la puesta en marcha. Parece ser la causa, sí.
  3. 1

    Cuando se crea un proceso en el depurador, el sistema operativo por defecto usa el montón de depuración. El montón de depuración hace más de verificación de la memoria, especialmente en el de-alloc.

    Hay varias opciones posibles para deshabilitar el uso de el Montón de Depuración:

    1. Adjuntar al proceso pronto después del inicio. Esto le permitirá acelerar el rendimiento en modo de depuración, a sabiendas, de modo y siendo plenamente conscientes de que el modo en el que se está ejecutando.

    2. Añadir la variable de entorno de configuración _NO_DEBUG_HEAP=1.

      Esto se puede establecer a nivel mundial para la máquina o para una instancia específica de Visual Studio.

      una. A nivel mundial, se establece una variable de entorno a través del Panel de Control → Sistema → configuración Avanzada del sistema → Variables de Entorno, y hay que añadir la variable _NO_DEBUG_HEAP=1.

      Nota: Esto tendrá un efecto en TODAS las aplicaciones de depuración.

      b. Para una instancia de Visual Studio puede abrir un símbolo del sistema, estableciendo la variable de entorno _NO_DEBUG_HEAP=1 y, a continuación, abra visual studio desde dentro de esa línea de comandos. Esto influirá sólo los procesos creados a partir de
      esa instancia de Visual Studio heredará el medio ambiente
      variable.

    3. Anexar el comportamiento del depurador, esto es posible para VS2015. Hay 2 maneras de anular esta:

      una. Para modificar para un proyecto específico, vaya a las propiedades del proyecto Propiedades de Configuración → Depuración y cambiar el Entorno de la propiedad _NO_DEBUG_HEAP a 1

      b. Para modificar para cada proyecto en Visual Studio, vaya a Herramientas → Opciones → Depuración y verificación de la opción: «Habilitar la depuración de Windows asignador de montón (sólo Nativo)».

      Nota: f el _NO_DEBUG_HEAP variable de entorno menciona en la ‘a’ se encuentra en un nivel de proyecto se va a reemplazar esta configuración global.

  4. 1

    Hay varias cosas que son diferentes si ejecuta la versión de depuración fuera de la IDE. Una de ellas es que el IDE tarda un poco en cargar los símbolos, y si usted depende de una gran cantidad de bibliotecas, a continuación, que el tiempo de inicio puede ser significativo.

    Si usted está usando un servidor de símbolos (incluyendo el público de Microsoft servidor de símbolos), a continuación, esto puede aumentar el tiempo de inicio, así que asegúrese de que usted tiene un símbolo local de la memoria caché de su _NT_SYMBOL_PATH variable si ese es el caso.

    También el IDE funciona con el montón de depuración activado, pero no creo que esto sucede si usted se ejecute fuera de la IDE.

    • Estoy usando el servidor de símbolos. Pero no estoy hablando de la hora de inicio, pero en el momento en que el programa utiliza para ejecutar. He de diagnóstico con std::cout, que tiene alrededor de uno por segundo con Ctrl+F5 y uno evvery 30 años o así, cuando runing con F5. Creo que el montón debbuging depende de la macro _DEBUG que va a hacer la comprobación del montón en ambos casos.
    • ¿Usted tiene cualquiera de los puntos de interrupción condicionales o puntos de seguimiento conjunto? Estos pueden retrasar la ejecución de una orden de magnitud. Pruebe a deshabilitar todos los puntos de interrupción temporal.
    • Lamentablemente no yo no tengo ningún ejemplo. Habría sido demasiado fácil 🙂
    • ¿Qué acerca de cualquier complementos? Otra cosa a probar es Monitor de Procesos en ejecución para ver si el devenv.exe proceso de acceso a los archivos. He encontrado algunos casos en los que esto sucede mucho, devenv mantiene acceder a mis archivos de encabezado. También intenta borrar el .suo archivo.
  5. 1

    Para mí la diferencia en el rendimiento entre el modo de depuración y el modo de disparador es acerca de un factor de 40. Después de algo de investigación, que aparece varias cosas que contribuyen a la diferencia en el rendimiento, pero hay una opción de compilador que cuádruples mi depurar un rendimiento casi gratis.

    Es decir, el cambio de /ZI en /Zi. Para ver una descripción, consulte la página de MSDN.

    Yo no uso la editar y continuar característica de todos modos.

  6. 0

    La depuración de Visual C++ viene con montones y montones de sobrecarga, especialmente en la STL. Trate de no definir _DEBUG, y definir NDEBUG.

    • Que no responda el OP pregunta, sin embargo-sigue siendo una versión de depuración, sólo se ejecuta fuera de la IDE. La STL diagnóstico se podrá ejecutar.
  7. 0

    Nadie ha mencionado cierre no utilizados de origen de windows.

    Tras el cierre de la 20+ sin usar windows, depuración de origen pisar fue de ~5s de vuelta a la ~.2s. Este inusualmente lenta proyecto carga una DLL de forma dinámica y que DLL también era el de ser un paso a través de (y tener fuente de windows abierto) por lo que parece probable relacionados. Sin embargo, esto fue C# (título y las etiquetas son no específicos).

    • sí escalonamiento de velocidad (ide interfaz de usuario de velocidad) es algo completamente diferente de lo que la ejecución de una aplicación
    • Veo, de verdad que espero que ayude a alguien que fue llevado de aquí.

Dejar respuesta

Please enter your comment!
Please enter your name here