¿Hay alguna (rendimiento) diferencia entre depuración y de lanzamiento?

Question

Estoy usando MySQL Connector .NET para cargar una cuenta y transferir al cliente. Esta operación es bastante intensiva, teniendo en cuenta los elementos secundarios de la cuenta a la carga.

Modo En Depuración, que se necesita, como máximo, 1 segundo para cargar la cuenta. El promedio sería de 500 ms. En el modo de lanzamiento, se tarda de 1 a 4 segundos para cargar la cuenta. El promedio sería de 1.500 ms.

Dado que no hay ninguna directiva #if DEBUG o similares en mi código, me pregunto donde la diferencia está viniendo.

¿Hay una opción de generación de proyecto que podría cambiar? O tiene que ver con MySQL Connector .NET que tienen diferentes comportamientos dependiendo del modo de acumulación?

Editar . Vigilancia de garrapatas

Debug (Average: 213000 ticks)
730000
320000
60000
50000
190000
130000
210000
180000
160000
110000
390000
270000
150000
190000
230000
210000
150000
200000
190000
140000

Release (Average: 4404500 ticks)
12940000
170000
180000
80000
80000
130000
120000
5060000
5090000
130000
50000
10430000
25160000
150000
160000
130000
17620000
10160000
100000
150000

Comparación:

Release toma 20x el tiempo de depuración toma (comparación promedio).

4404500 / 213.000 = 20

Ahora, la primera operación es de hecho más, pero en general, también lo son todas las otras veces para la liberación. Alguna idea?

EDIT 2 : He añadido incluso unas pruebas más amplias que calcula el tiempo total. Para cargas de 50 de cuenta, se necesita un promedio de 4 segundos en depura, y 40 segundos en la liberación. Estoy empezando a llegar a ser muy desesperada por esto - es un grave problema de rendimiento para mi aplicación. ¿Alguien tiene una conjetura sobre cómo solucionar este problema?

Answer 1

lo he descubierto, que permitió código no seguro en una de mis dependencias de construcción. Todavía estoy preguntando por qué se comporta así, pero voy a tener que cavar esto un poco más.

Gracias por toda su ayuda!

Answer 2

Es posible que la diferencia en los tiempos se debe a un cambio en las asambleas cuando se requieren para su operación se cargan.

En el modo de lanzamiento, el tiempo de ejecución puede no necesitar para cargar inmediatamente un ensamblado que se sólo más tarde requerido por su funcionamiento (debido a varias optimizaciones realizadas para las versiones de lanzamiento). En consecuencia, en el modo de depuración un montaje puede quedar cargado antes de empezar a tiempo de su operación, y en modo de lanzamiento que el montaje puede conseguir carga después de empezar a tiempo de su operación. El tiempo para cargar el ensamblado podría ser significativo dependiendo del tamaño de la asamblea es. Por supuesto, el conjunto tiene que ser cargado en ambos casos, y sólo tiene que ser cargado una vez, así ejecuciones posteriores en el modo de liberación puede ser más rápido.

Trate de realizar la operación varias veces dentro de un bucle y haciendo caso omiso de la primera ejecución de encontrar el término medio menos comenzar encima de la cabeza.

Actualización: Es interesante que los tiempos en el modo de disparo varían mucho en comparación con aquellos en el modo de depuración (el std dev es 100 veces más alta para el modo de disparo). En el extremo inferior, las temporizaciones de modo de liberación son comparables a los del modo de depuración. Usted menciona en su pregunta que la carga de una cuenta es intensiva debido a todos los elementos secundarios que tienen de carga. Otra diferencia podría ser el punto en el que el tiempo de ejecución decide llevar a cabo la recolección de basura. Para la prueba, usted podría intentar realizar System.GC.Collect() después de cada operación (fuera de su contador de tiempo) y ver si eso cambia las cosas.

Actualización: Si sospecha que puede haber un cambio en el comportamiento con respecto al bloqueo, es posible considerar el uso del Windows Monitor de rendimiento para supervisar los diversos contadores LocksAndThreads .NET CLR durante el proceso de su aplicación (es) mientras ejecuta sus pruebas en ambos modos de depuración y liberación . Tal vez usted no está liberando correctamente un bloqueo en algún lugar y ejecución se retrasa hasta algunos lapsos de tiempo de espera? Si es así, yo esperaría a ver un aumento en la tasa de contención reportado por los contadores de rendimiento. No estoy seguro de por qué esto sólo sería un problema para las versiones de lanzamiento (a menos que en realidad estás utilizando el depurador cuando se ejecutan versiones de depuración).

Answer 3

Todo sobre las pestañas de compilación y de depuración en la configuración de propiedades de aplicación puede cambiar dependiendo de la configuración de generación. Algunas de ellas se refieren sólo a la etapa de compilación y no afectará el rendimiento en tiempo de ejecución (Permitir código no seguro, Errores y avisos, advertencias tratan como errores, y el archivo XML Documenation). Los otros podrían hacer la diferencia.

Me tomaría nota de cada ajuste que es diferente entre las configuraciones, a continuación, cambiar cada uno para que las configuraciones coinciden, prueba entre cada cambio. Entonces usted debería ser capaz de encontrar la fuente del problema.

En especial me prueba Definir constante de depuración, Definir constante TRACE, símbolos de compilación condicional, Destino de la plataforma, el código Optimizar, (en la pantalla avanzada) Compruebe si la aritmética desbordamiento / subdesbordamiento, Generar serialización montaje, Habilitar depuración de código no administrado y Habilitar la proceso de alojamiento de visual Studio.