Diferencias de rendimiento entre versiones de depuración y versión

Debo admitir que, por lo general, no me he molestado en cambiar entre las configuraciones de depuración y liberación en mi progtwig, y ​​generalmente he optado por ir a la configuración de depuración , incluso cuando los progtwigs se implementan realmente en el lugar del cliente.

Por lo que yo sé, la única diferencia entre estas configuraciones si no la cambias manualmente es que Debug tiene definida la constante DEBUG , y Release tiene el código de Optimize activado.

Entonces mis preguntas son en realidad dos cosas:

  1. ¿Hay muchas diferencias de rendimiento entre estas dos configuraciones? ¿Hay algún tipo específico de código que cause grandes diferencias en el rendimiento aquí, o en realidad no es tan importante?

  2. ¿Hay algún tipo de código que se ejecutará correctamente en la configuración de depuración que puede fallar en la configuración de la versión o puede estar seguro de que el código que se prueba y funciona correctamente en la configuración de depuración también funcionará bien en la configuración de la versión.

El propio comstackdor de C # no altera mucho la IL emitida en la comstackción Release. Es notable que ya no emite los códigos de operación NOP que le permiten establecer un punto de interrupción en una llave. El más grande es el optimizador que está integrado en el comstackdor JIT. Sé que hace las siguientes optimizaciones:

  • Método en línea Una llamada a método se reemplaza por la inyección del código del método. Este es uno grande, hace que los accesadores de propiedades sean esencialmente gratuitos.

  • Asignación de registro de CPU Las variables locales y los argumentos del método pueden permanecer almacenados en un registro de la CPU sin almacenarse nunca (o con menos frecuencia) en el marco de la stack. Este es uno grande, notable por hacer que el código optimizado para la depuración sea tan difícil. Y dando a la palabra clave volátil un significado.

  • Eliminación de comprobación de índice de matriz. Una optimización importante cuando se trabaja con matrices (todas las clases de colección .NET usan una matriz internamente). Cuando el comstackdor JIT puede verificar que un bucle nunca indexa una matriz fuera de límites, eliminará la verificación del índice. Uno grande.

  • Loop se desenrolla. Los bucles con cuerpos pequeños se mejoran repitiendo el código hasta 4 veces en el cuerpo y girando menos. Reduce el costo de la sucursal y mejora las opciones de ejecución súper-escalares del procesador.

  • Eliminación del código muerto. Una statement como if (false) {/ /} se elimina por completo. Esto puede ocurrir debido al doblado constante y la alineación. En otros casos, el comstackdor JIT puede determinar que el código no tiene un efecto secundario posible. Esta optimización es lo que hace que el código de perfiles sea tan complicado.

  • Código de elevación. El código dentro de un bucle que no se ve afectado por el bucle puede moverse fuera del bucle. El optimizador de un comstackdor de C pasará mucho más tiempo buscando oportunidades para izar. Sin embargo, es una optimización costosa debido al análisis de flujo de datos requerido y la fluctuación de fase no puede permitirse el tiempo, por lo que solo se alzan casos obvios. Obligando a los progtwigdores de .NET a escribir mejor código fuente y a elevar ellos mismos.

  • Eliminación de sub-expresión común. x = y + 4; z = y + 4; se convierte en z = x; Muy común en declaraciones como dest [ix + 1] = src [ix + 1]; escrito para facilitar la lectura sin introducir una variable auxiliar. No es necesario comprometer la legibilidad.

  • Plegado constante. x = 1 + 2; se convierte en x = 3; Este simple ejemplo es captado antes por el comstackdor, pero ocurre en el momento de JIT cuando otras optimizaciones lo hacen posible.

  • Copiar propagación. x = a; y = x; se convierte en y = a; Esto ayuda al asignador de registro a tomar mejores decisiones. Es un gran problema en el jitter x86 porque tiene pocos registros para trabajar. Tenerlo seleccionar los correctos es fundamental para perf.

Estas son optimizaciones muy importantes que pueden marcar una gran diferencia cuando, por ejemplo, usted perfila la comstackción Debug de su aplicación y la compara con la versión Release. Sin embargo, eso solo importa cuando el código está en su ruta crítica, el 5 al 10% del código que escribe afecta realmente la ejecución de su progtwig. El optimizador JIT no es lo suficientemente inteligente como para saber por adelantado lo que es crítico, solo puede aplicar el dial “turn it to once” para todo el código.

El resultado efectivo de estas optimizaciones en el tiempo de ejecución de su progtwig a menudo se ve afectado por el código que se ejecuta en otro lugar. Leer un archivo, ejecutar una consulta de base de datos, etc. Hacer que el trabajo del optimizador de JIT sea completamente invisible. No importa, 🙂

El optimizador JIT es un código bastante confiable, sobre todo porque ha sido probado millones de veces. Es extremadamente raro tener problemas en la versión de versión de lanzamiento de su progtwig. Sucede sin embargo. Tanto el nerviosismo x64 como el x86 han tenido problemas con las estructuras. El jitter x86 tiene problemas con la consistencia de coma flotante, produciendo resultados sutilmente diferentes cuando los intermedios de un cálculo de punto flotante se mantienen en un registro FPU con una precisión de 80 bits en lugar de truncarse cuando se vacían a la memoria.

  1. Sí, hay muchas diferencias de rendimiento y realmente se aplican en todo su código. Debug hace muy poca optimización del rendimiento y mucho más el modo de lanzamiento;

  2. Solo el código que se basa en la constante DEBUG puede funcionar de forma diferente con una versión de lanzamiento. Además de eso, no deberías ver ningún problema.

Un ejemplo de código de marco que depende de la constante DEBUG es el método Debug.Assert() , que tiene el atributo [Conditional("DEBUG)"] definido. Esto significa que también depende de la constante DEBUG y esto no está incluido en la versión de lanzamiento.

Esto depende en gran medida de la naturaleza de su aplicación. Si su aplicación está cargada de UI, probablemente no notará ninguna diferencia ya que el usuario es el componente más lento conectado a una computadora moderna. Si utiliza algunas animaciones de UI, es posible que desee probar si puede percibir un retraso notable cuando se ejecuta en la creación DEBUG.

Sin embargo, si tiene muchos cálculos de cómputo pesado, notará diferencias (podría ser tan alto como 40% como se menciona en @Pieter, aunque dependería de la naturaleza de los cálculos).

Es básicamente una compensación de diseño. Si está lanzando bajo DEBUG build, entonces si los usuarios experimentan problemas, puede obtener un traceback más significativo y puede hacer un diagnóstico mucho más flexible. Al liberar en la comstackción DEBUG, también evitas que el optimizador produzca Heisenbugs oscuros.

  • Mi experiencia ha sido que las aplicaciones de tamaño mediano o más grandes son notablemente más receptivas en una comstackción de versión. Pruébelo con su aplicación y vea cómo se siente.

  • Una cosa que puede morderte con las comstackciones de Release es que el código de comstackción de Debug a veces puede suprimir las condiciones de carrera y otros errores relacionados con el subprocesamiento. El código optimizado puede dar como resultado el reordenamiento de la instrucción y una ejecución más rápida puede exacerbar ciertas condiciones de carrera.

Nunca debe lanzar una versión .NET Debug en la producción. Puede contener código feo para admitir Edit-and-Continue o quién sabe qué más. Hasta donde yo sé, esto sucede solo en VB, no en C # (nota: la publicación original está etiquetada como C #) , pero aún debería dar razón para detenerse en cuanto a lo que Microsoft piensa que pueden hacer con una comstackción de depuración. De hecho, antes de .NET 4.0, el código VB filtra la memoria proporcional a la cantidad de instancias de objetos con eventos que construye para soportar Edit-and-Continue. (Aunque se informa que esto se solucionó por https://connect.microsoft.com/VisualStudio/feedback/details/481671/vb-classes-with-events-are-not-garbage-collected-when-debugging , el código generado parece desagradable, crear objetos WeakReference y agregarlos a una lista estática mientras se mantiene un locking ) ¡Ciertamente no quiero este tipo de soporte de depuración en un entorno de producción!

En mi experiencia, lo peor que ha salido del modo de lanzamiento son los oscuros “errores de liberación”. Dado que el IL (lenguaje intermedio) está optimizado en modo Release, existe la posibilidad de que no se hayan manifestado errores en el modo Debug. Hay otras preguntas de SO que cubren este problema: Los motivos comunes para los errores en la versión de lanzamiento no están presentes en el modo de depuración

Me ha sucedido una o dos veces que una aplicación de consola simple funcionaría perfectamente bien en el modo de depuración, pero dada la misma entrada exacta, el error saldría en el modo de lanzamiento. Estos errores son EXTREMADAMENTE difíciles de depurar (por definición, del modo Release, irónicamente).

Yo diría que 1) depende en gran medida de su implementación. Por lo general, la diferencia no es tan grande. Hice muchas mediciones y, a menudo, no pude ver la diferencia. Si usa código no administrado, muchas matrices enormes y cosas así, la diferencia de rendimiento es un poco mayor, pero no un mundo diferente (como en C ++). 2) Por lo general, en el código de versión se muestran menos errores (mayor tolerancia), por lo tanto, un interruptor debería funcionar bien.

  **Debug Mode:** Developer use debug mode for debugging the web application on live/local server. Debug mode allow developers to break the execution of program using interrupt 3 and step through the code. Debug mode has below features: 1) Less optimized code 2) Some additional instructions are added to enable the developer to set a breakpoint on every source code line. 3) More memory is used by the source code at runtime. 4) Scripts & images downloaded by webresource.axd are not cached. 5) It has big size, and runs slower. **Release Mode:** Developer use release mode for final deployment of source code on live server. Release mode dlls contain optimized code and it is for customers. Release mode has below features: More optimized code Some additional instructions are removed and developer can't set a breakpoint on every source code line. 1) Less memory is used by the source code at runtime. 2) Scripts & images downloaded by webresource.axd are cached. 3) It has small size, and runs fast. 4) Scripts & images downloaded by webresource.axd are cached. 5) It has small size, and runs fast.