Código de C# muy lento con el depurador conectado; ¿Error de MemoryMappedFile?

Question

Tengo una aplicación cliente/servidor. El componente del servidor se ejecuta, utiliza WCF de forma 'remota' (formateador binario, objetos de sesión).

Si comienzo el componente del servidor y ejecuto el cliente, la primera tarea que completa el servidor es < 0.5sec.

Si comienzo el componente del servidor con el depurador VS adjunto, y luego ejecuto el cliente, la tarea tarda más de 20 segundos en completarse.

No hay cambios en el código, no hay cambios en la compilación condicional. Lo mismo ocurre si tengo el componente del servidor compilado y ejecutándose en 32 bits, 64 bits, con el proceso de alojamiento de VS, sin el proceso de alojamiento VS, o cualquier combinación de esas cosas.

Posiblemente importante: Si utilizo el VS.NET perfilador (modo de muestreo), entonces la aplicación se ejecuta tan rápido como si no hubiera un depurador asociado. Entonces no puedo diagnosticarlo de esa manera. Acabo de comprobar, el modo de instrumentación también se ejecuta rápidamente. Lo mismo para el modo de perfil de concurrencia, funciona rápidamente.

datos clave:

• La aplicación utiliza múltiples hilos bastante pesado (40 hilos en el grupo de subprocesos estándar). La creación de los hilos pasa rápidamente independientemente y no es un punto lento. Hay muchos bloqueos, WaitHandle sy Monitor patrones
• La aplicación no genera excepciones en absoluto.
• La aplicación no crea salida de consola.
• La aplicación es código completamente administrado.
• La aplicación no mapa algunos archivos en el disco a un archivo proyectado en memoria: 1x750MB y 12x8MB y algunos más pequeños

rendimiento medido:

• uso de la CPU es mínimo en ambos casos; cuando el depurador está conectado, la CPU se encuentra en < 1%
• El uso de memoria es mínimo en ambos casos; tal vez 50 o 60 MB en ambos casos
• hay un montón de fallos de página que suceden (MMF ref), sin embargo de que se produzcan más lentamente cuando el depurador asociado
• Si no se utiliza el proceso de alojamiento VS, o básicamente la 'depuración remota monitor 'entra en juego, entonces que usa una cantidad decente de CPU y crea un buen número de fallas de página. Pero esa no es la única vez que ocurre el problema
• La diferencia en el rendimiento se ve independientemente de cómo se ejecute el cliente. La única variable que se cambia es el componente del servidor que se ejecuta a través de "Iniciar con la depuración" frente a la iniciada desde el Explorador.

Mis ideas:

• WCF lento cuando depurado?
• MemoryMappedFile ¿se ralentiza cuando se depura?
• 40 hilos utilizados: ¿lento para depurar? Tal vez Monitors/locks notifique depurador?La programación de subprocesos se vuelve extraña/los cambios de contexto son muy poco frecuentes?
• radiación de fondo de la concesión de la inteligencia y cruel sentido del humor para VS

Todo parece poco probable estúpidamente.

lo tanto, mi pregunta:

1. Por qué sucede esto?
2. Si se desconoce el n. ° 1, ¿cómo puedo diagnosticar/averiguar?

Answer 1

Las excepciones pueden afectar notablemente el rendimiento de una aplicación. Hay dos tipos de excepciones: excepciones de la primera oportunidad (la que se maneja con gracia con un bloque try/catch) y excepciones no controladas (que finalmente bloquearán la aplicación).

De forma predeterminada, el depurador no muestra excepciones de la primera oportunidad, solo muestra excepciones no controladas. Y de forma predeterminada, también muestra solo las excepciones que ocurren en su código. Sin embargo, incluso si no los muestra, aún los maneja, por lo que su rendimiento puede verse afectado (especialmente en las pruebas de carga o las ejecuciones de bucles grandes).

Para habilitar excepciones de primera oportunidad en Visual Studio, haga clic en "Depurar | Excepciones" para invocar el cuadro de diálogo Excepciones y marque "Lanzado" en la sección "Common Language Runtime" (puede ser más específico y elegir cuál excepción de oportunidad que desea ver).

Para habilitar la exhibición de excepciones de 1era oportunidad originada desde cualquier lugar de la aplicación, no solo desde su código, haga clic en "Herramientas | Opciones | Depuración | General" y deshabilite la opción "Habilitar simplemente mi código".

Y para estos casos específicos de "modo forense", también recomiendo habilitar .NET Framework Source Stepping (se requiere habilitar Enable My My Code). Es muy útil para entender lo que está pasando, a veces sólo mirar la pila de llamadas es muy inspirador - y servicial, especialmente en el caso de confusión radiación cósmica :-)

Dos interesantes artículos relacionados:

• How to debug crashes and hangs
• Configuring Visual Studio to Debug .NET Framework Source Code

Answer 2

ya que este es uno de los primeros resultados cuando Google para este tema me gustaría añadir mi solución problema aquí con la esperanza de salvar a alguien 2 horas de investigación, como he en mi caso

Mi código disminuyó de 30 segundos sin depurador conectado a 4 minutos con el depurador. porque olvidé eliminar un punto de interrupción condicional. Estos parecen ralentizar la ejecución tremendamente, así que ten cuidado con aquellos