Código C# muy lento con el depurador adjunto; ¿Falla de Memory MappedFile?

Question

Tengo una aplicación de cliente/servidor. El componente del servidor se ejecuta, utiliza WCF en una moda de 'Remoting' (Formatero binario, objetos de sesión).

Si inicio el componente del servidor y loto el cliente, la primera tarea que el servidor realiza en <0.5sec.

Si inicio el componente del servidor con VS depurador adjunto, y luego lanzar el cliente, la tarea toma más de 20 segundos para completar.

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

Posiblemente importante: Si uso el vs.net perfilador (Modo de muestreo), entonces la aplicación se ejecuta tan rápido como si no hubiera un depurador adjunto. Así que no puedo diagnosticarlo de esa manera. Acabo de verificar, el modo de instrumentación también se ejecuta rápidamente. Lo mismo para el modo de perfil de concurrencia, funciona rápidamente.

Llave de datos:

• La aplicación utiliza multithreading bastante pesado (40 hilos en el grupo de hilos estándar). Crear los hilos ocurre rápidamente independientemente y no es un punto lento. Hay muchas cerraduras, WaitHandlearena Monitor patrones
• La aplicación no plantea excepciones en absoluto.
• La aplicación no crea salida de consola.
• La aplicación es un código completamente administrado.
• La aplicación asigna algunos archivos en el disco a un archivo de memoria mapeada: 1x750mb y 12x8mb y algunos más pequeños

Rendimiento medido:

• El uso de la CPU es mínimo en ambos casos; Cuando se adjunta el depurador, la CPU se encuentra en <1%
• El uso de la memoria es mínimo en ambos casos; tal vez 50 o 60 MB en ambos casos
• Hay muchas fallas de página (Ref MMF), sin embargo, ocurren más lentamente cuando se adjunta el depurador
• Si no se utiliza el proceso de alojamiento VS, o básicamente el 'monitor de depuración remota' entra en juego, entonces que Utiliza una cantidad decente CPU y crea una buena cantidad de fallas de página. Pero esa no es la única vez que está ocurriendo el problema
• La diferencia de 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 la depuración' vs lanzado desde Explorer.

Mis ideas:

• ¿WCF lento cuando se depugga?
• ¿Los archivos de memoria lentos cuando se depuran?
• 40 hilos utilizados: ¿lento para depurar? ¿Quizás los monitores/cerraduras notifiquen el depurador? ¿La programación de hilos se vuelve extraña/contexto de contexto muy poco frecuente?
• Radiación de antecedentes cósmicos que otorga inteligencia y cruel sentido del humor a VS

Todos parecen estúpidamente improbables.

Entonces, mis preguntas:

1. ¿Por qué está pasando esto?
2. Si #1 desconocido, ¿cómo puedo diagnosticar / averiguarlo?

Answer 1

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

Por defecto, el depurador no muestra las primeras excepciones de la oportunidad, solo muestra excepciones no controladas. Y de forma predeterminada, también muestra solo 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 grandes ejecuciones de bucle).

Para habilitar la visualización de excepciones de la primera oportunidad en Visual Studio, haga clic en "Depurar | Excepciones" para invocar el cuadro de diálogo Excepciones y verifique "lanzado" en la sección "tiempo de ejecución del lenguaje común" (puede ser más específico y elegir la 1ra excepción de la oportunidad que desee que desee para ver).

Para habilitar la visualización de excepciones de la primera oportunidad que se origina 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 solo mi código".

Y para estos casos específicos de "modo forense", también recomiendo encarecidamente habilitar el paso de fuente de .NET Framework (requiere "habilitar solo mi código" para deshabilitar). Es muy útil comprender lo que está sucediendo, a veces solo mirar la pila de llamadas es muy inspiradora, y es útil especialmente en el caso de la mezcla de radiación cósmica :-)

Dos artículos interesantes relacionados:

• Cómo depurar accidentes y colgados
• Configuración de Visual Studio para depurar el código fuente de .NET Framework

Answer 2

Dado que este es uno de los primeros resultados en Google para este problema, me gustaría agregar mi solución de problemas aquí con la esperanza de salvar a alguien 2 horas de investigación como en mi caso.

Mi código se ralentizó de 30 segundos sin depurador adjunto a 4 minutos con el depurador. Porque olvidé eliminar un punto de interrupción condicional. Estos parecen frenar enormemente la ejecución, así que ten cuidado con esos