¿Iniciar LAN Profiler aumenta el rendimiento de la aplicación x20?

Question

EDIT 1
no excluyo en absoluto que esto podría ser causado por algo efecto secundario muy básica de usar el Analizador (un cierto ajuste defectuoso en mi proyecto "regular")

quería mejorar Computing Tiempo en mi aplicación, así que decidí pasar por un análisis exhaustivo de perfiles. Entonces Acabo de lanzar un .Net Memory Allocation Profiling para analizar mi aplicación.
Estaba completamente aturdido al ver la computación va x20 veces más rápido!

La aplicación consiste en leer datos de archivos binarios con BackgroundWorkers, procesarlos,
y almacenar resultados en una base de datos MSSQL. Cada ronda por lo general toma 20 segundos, y mientras que el perfil apenas toma 1 seg. Revisé y me aseguré de que los resultados fueran coherentes en ambos casos.

Un amigo experimentado de .Net me dijo que el generador de perfiles optimiza el enhebrado y que "de alguna manera" encuentra su camino a través del hilo Locks and Bottlenecks, pero no puedo creerlo.

Así que mis preguntas son:

1. ¿Qué es exactamente lo que pase, cómo y por qué?
2. ¿Cómo hacer que mi código se comporte así de forma nativa?

EDIT 2
I SÉ esto suena loco e increíble. Yo mismo todavía soy muy sospechoso. Pero es VERDADERO.
El código SAME se ejecuta muy rápido cuando lo ejecuta el generador de perfiles. Uso los MISMOS datos de prueba, y miro la MISMA salida informática. No puedo dar un simple proyecto de reproducción, ya que es un marco relativamente grande. Estoy usando el Visual Studio 2010 Profiler.

Voy a dar todos los detalles que pueda sobre el flujo y definitivamente publicaré una pista tan pronto como lo encuentre.

REGISTROS RUN regulares:
03/23/2011 18:04:34 | 180434.621 | JUEGO DE SIMULACIÓN [5] - [1] - [5 PC-1 0 [SET 1/48]
23/03/2011 18:05:01 | 180501.271 | PROCESAMIENTO DE TIEMPO: 00: 00: 26,6515244
etc ..

REGISTROS

Profiler Run:
03/24/2011 11:38:15 | 113815.592 | JUEGO DE SIMULACIÓN [5] - [1] - [5 PC-1 0 [SET 1/48]
24/03/2011 11:38:17 | 113817.350 | PROCESAMIENTO DE TIEMPO: 00: 00: 01,7581005

etc ..

Datos 3: La pista
Ok ok ok mi mal (advertí en esa posibilidad de editar 1, ya que era demasiado increíble Lo siento) @Watts sugirió verificar si estaba en modo depuración o versión. que ya he hecho. PERO @SnowBear señaló que hay dos cosas diferentes: ejecutar la versión de depuración del software y ejecutar un software bajo el depurador . Me aseguré de que la configuración activa fuera LIBERACIÓN tanto en la compilación como en la ejecución VS2010. Sin embargo, como me estaba volviendo loco, decidí lanzar la Aplicación directamente desde el archivo exe en el bin/release. Y voilà ... los procesos tardaban 1 segundo cada uno. Ejecutando Profiler para salir del modo de depuración (ya sea que esté en modo de liberación o depuración) eso es lo que me confunde.
Gracias a All Case Closed.

Answer 1

Al ejecutar con el depurador se deshabilitan las optimizaciones de jit. Si ejecuta el exe normalmente las optimizaciones de jit se habilitarán. La conexión de un depurador a una aplicación en ejecución de este tipo le permite depurarlo con optimizaciones habilitadas.

Release-Construir vs depuración y Construcción tiene dos consecuencias:

1. Un símbolo compilador condicional es de (des) define
2. Se activa/desactiva las optimizaciones en el C# => IL compilación.

Answer 2

Teniendo en cuenta que la pregunta se refiere a código que se ejecuta más rápido en el generador de perfiles, y que las preguntas específicas son "1. ¿qué sucede, cómo y por qué? Y 2. ¿Cómo hacer mi código se comportan de esa manera nativa? " la respuesta aceptada es incorrecta, ya que no aborda el perfilador en absoluto, ni menciona la causa específica de la aceleración de 20x.

Lo que ocurre es exactamente este:

En la pestaña de "depuración" de las propiedades del proyecto está marcada la casilla de verificación "Habilitar la depuración de código no administrado"; esta opción hace que el depurador sea lento como melaza.

Cuando ejecuta el generador de perfiles, sigue siendo la versión de depuración de su programa que está perfilando, por lo que el símbolo "DEPURAR" está definido, y todas las aserciones, etc. están habilitadas, pero el depurador no está involucrado, por lo que la opción "Habilitar la depuración del código no administrado" no es aplicable. (Las optimizaciones de JIT probablemente estén habilitadas durante el perfilado, pero eso no representaría ni siquiera un aumento del rendimiento de 2x, y mucho menos un impulso de 20x).

Si desea disfrutar de este aumento de 20x al depurar su código, (no solo mientras perfila ,) vaya a la pestaña "Depurar" de las propiedades de su proyecto y asegúrese de que "Habilitar la depuración del código no administrado" esté desmarcada.

P.S.

hay una pregunta que es duplicado unos pocos meses de más edad de éste: How Come when I sampling profile a program and it actually runs faster than not profiling?

Answer 3

Me he encontrado con esto muchas veces ... Hay una explicación muy simple para ello. El generador de perfiles no dispone de objetos, por lo que no se incurre en el costo de eliminación del objeto durante el perfilado.

Por lo tanto, si desea mejorar el rendimiento para que coincida con el rendimiento perfilado, averigüe dónde está instanciando todos estos objetos efímeros y refactorice el código.

Todavía no conozco una forma excelente de encontrar inmediatamente el código ofensivo, pero puedo ayudarlo a reducirlo. Si perfila su código, abre el informe, selecciona "Funciones" como tu Vista actual y luego ordena por Muestras inclusivas, verás los mejores métodos ... Tu problema de rendimiento con las instancias de objetos es probable que esté en uno de esos métodos con las muestras más inclusivas.