Diferencias de rendimiento entre compilaciones de depuración y versiones

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

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

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

Esto depende en gran medida de la naturaleza de su aplicación. Si su aplicación es IU-heavy, probablemente no notará ninguna diferencia ya que el componente más lento conectado a un equipo moderno es el usuario. Si utiliza algunas animaciones de interfaz de usuario, es posible que desee probar si puede percibir algún retraso notable cuando se ejecuta en la compilación de DEPURACIÓN.

Sin embargo, si tiene muchos cálculos pesados de computación, entonces notará diferencias (podrían ser tan altas como el 40% como mencionó @Pieter, aunque lo haría depende de la naturaleza de los cálculos).

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

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

• Una cosa que puede morderte con las compilaciones de versiones es que el código de compilación de depuración a veces puede suprimir las condiciones de carrera y otros errores relacionados con el subproceso. El código optimizado puede dar lugar a un reordenamiento de las instrucciones y una ejecución más rápida puede exacerbar ciertas condiciones de carrera.

Nunca debe lanzar una compilación de depuración. NET en producción. Puede contener código feo para soportar Editar y Continuar o quién sabe qué más. Por lo que sé, esto sucede solo en VB no en C# (nota: la publicación original está etiquetada con C#), pero todavía debería dar razones para hacer una pausa en cuanto a lo que Microsoft piensa que se les permite hacer con una compilación de depuración. De hecho, antes de. NET 4.0, el código VB pierde memoria de forma proporcional al número de instancias de objetos con eventos que se construyen en apoyo de Editar y Continuar. (Aunque esto se informa que se fija por https://connect.microsoft.com/VisualStudio/feedback/details/481671/vb-classes-with-events-are-not-garbage-collected-when-debugging, el código generado se ve desagradable, creando WeakReference objetos y agregándolos a una lista estática mientras mantiene un bloqueo) Ciertamente no quiero ningún tipo de este tipo de soporte de depuración en un entorno de producción!

En mi experiencia, lo peor que ha salido del modo de liberación son los oscuros "errores de liberación". Dado que el IL (lenguaje intermedio) está optimizado en el modo de liberación, existe la posibilidad de errores que no se habrían manifestado en el modo de depuración. Hay otras preguntas que cubren este problema: Razones comunes para que los errores en la versión de lanzamiento no estén presentes en el modo de depuración

Esto me ha pasado una o dos veces donde una simple aplicación de consola se ejecutaría perfectamente bien en Debug modo, pero dada la misma entrada exacta, se produciría un error en el modo de liberación. Estos errores son extremadamente difíciles de depurar (por definición del modo de liberación, 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 podía ver la diferencia. Si usas código no administrado, muchas matrices enormes y cosas por el estilo, 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 lanzamiento 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.