c# - Rendimiento de Debug vs. Release
performance debugging (9)
He encontrado el siguiente párrafo:
"La configuración de depuración frente a versión en el IDE cuando compila su código en Visual Studio casi no hace diferencia en el rendimiento ... el código generado es casi el mismo. El compilador C # realmente no hace ninguna optimización. El compilador de C # solo escupe IL ... y en el tiempo de ejecución es el JITer el que hace toda la optimización. El JITer tiene un modo de depuración / liberación y eso hace una gran diferencia en el rendimiento. Pero eso no aclara si ejecuta la configuración de Debug o Release de su proyecto, eso desactiva si se adjunta un depurador ".
La fuente está here y el podcast está here .
¿Puede alguien dirigirme a un artículo de Microsoft que realmente pueda probar esto?
Google " depuración de C # frente a rendimiento de publicación " en su mayoría devuelve resultados que dicen " depuración tiene un montón de impacto de rendimiento ", " lanzamiento está optimizado " y " no implementar depuración en producción ".
De msdn social
No está bien documentado, esto es lo que sé. El compilador emite una instancia de System.Diagnostics.DebuggableAttribute. En la versión de depuración, la propiedad IsJitOptimizerEnabled es True, en la versión de lanzamiento es False. Puede ver este atributo en el manifiesto de ensamblaje con ildasm.exe
El compilador JIT usa este atributo para deshabilitar las optimizaciones que dificultarían la depuración. Los que mueven el código como un alzado invariante de bucle. En casos seleccionados, esto puede marcar una gran diferencia en el rendimiento. Aunque no suele ser así.
La asignación de puntos de interrupción a las direcciones de ejecución es tarea del depurador. Utiliza el archivo .pdb y la información generada por el compilador JIT que proporciona la instrucción IL a la asignación de direcciones de código. Si escribiera su propio depurador, usaría ICorDebugCode :: GetILToNativeMapping ().
Básicamente, la implementación de depuración será más lenta ya que las optimizaciones del compilador JIT están desactivadas.
En el sitio msdn ...
Configuraciones de liberación frente a depuración
Mientras todavía está trabajando en su proyecto, normalmente construirá su aplicación utilizando la configuración de depuración, porque esta configuración le permite ver el valor de las variables y controlar la ejecución en el depurador. También puede crear y probar compilaciones en la configuración de lanzamiento para asegurarse de que no ha introducido ningún error que solo se manifieste en un tipo de compilación u otro. En la programación de .NET Framework, tales errores son muy raros, pero pueden ocurrir.
Cuando esté listo para distribuir su aplicación a los usuarios finales, cree una versión de lanzamiento, que será mucho más pequeña y generalmente tendrá un rendimiento mucho mejor que la configuración de depuración correspondiente. Puede configurar la configuración de compilación en el panel Generar del Diseñador de proyectos o en la barra de herramientas Compilar. Para obtener más información, vea Configuraciones de compilación.
En gran medida, eso depende de si su aplicación está vinculada a cómputo, y no siempre es fácil de decir, como en el ejemplo de Lasse. Si tengo la menor pregunta sobre lo que está haciendo, lo paro un par de veces y examino la pila. Si hay algo extra que realmente no necesitaba, eso lo detecta de inmediato.
Lo que lees es bastante válido. La liberación suele ser más pobre debido a la optimización JIT, sin incluir el código de depuración (#IF DEBUG o [Conditional ("DEBUG")]), la carga mínima del símbolo de depuración ya menudo no se considera un ensamblaje más pequeño que reducirá el tiempo de carga. El rendimiento diferente es más obvio cuando se ejecuta el código en VS debido a PDB y símbolos más extensos que se cargan, pero si se ejecuta de forma independiente, las diferencias de rendimiento pueden ser menos evidentes. Cierto código se optimizará mejor que otros y está utilizando la misma heurística de optimización al igual que en otros idiomas.
Scott tiene una buena explicación sobre la optimización de métodos en línea here
Consulte este artículo que ofrece una breve explicación de por qué es diferente en el entorno ASP.NET para la configuración de depuración y liberación.
No hay ningún artículo que "pruebe" algo sobre una pregunta de rendimiento. La forma de demostrar una afirmación sobre el impacto en el rendimiento de un cambio es probarlo en ambos sentidos y probarlo en condiciones realistas pero controladas.
Está haciendo una pregunta sobre el rendimiento, por lo que claramente le importa el rendimiento. Si le importa el rendimiento, entonces lo correcto es establecer algunos objetivos de rendimiento y luego redactarse un conjunto de pruebas que rastree su progreso en relación con esos objetivos. Una vez que tenga un conjunto de pruebas de este tipo, podrá usarlo fácilmente para probar la verdad o la falsedad de afirmaciones como "la compilación de depuración es más lenta".
Y además, podrás obtener resultados significativos. "Más lento" no tiene sentido porque no está claro si es un microsegundo más lento o veinte minutos más lento. "10% más lento en condiciones realistas" es más significativo.
Dedique el tiempo que habría dedicado a investigar esta pregunta en línea sobre la construcción de un dispositivo que responda la pregunta. Obtendrás resultados mucho más precisos de esa manera. Todo lo que lees en línea es solo una suposición sobre lo que podría pasar. Razón de los hechos que usted reunió, no de las suposiciones de otras personas sobre cómo podría comportarse su programa.
No puedo hacer ningún comentario sobre el rendimiento, pero el consejo de "no implementar depuración en la producción" todavía se cumple porque el código de depuración generalmente hace bastantes cosas de manera diferente en productos grandes. Por un lado, es posible que tenga conmutadores de depuración activos y, por otro, probablemente haya comprobaciones de cordura redundantes adicionales y salidas de depuración que no pertenecen al código de producción.
Parcialmente cierto. En modo de depuración, el compilador emite símbolos de depuración para todas las variables y compila el código tal como está. En el modo de lanzamiento, se incluyen algunas optimizaciones:
- las variables no utilizadas no se compilan en absoluto
- el compilador saca algunas variables de bucle del bucle si se demuestra que son invariantes
- el código escrito bajo la directiva #debug no está incluido, etc.
El resto depende del JIT.
Editar: lista completa de optimizaciones here cortesía de Eric Lippert
Recientemente me encontré con un problema de rendimiento. La lista completa de productos tomaba demasiado tiempo, unos 80 segundos. Sintonicé el DB, mejoré las consultas y no hubo ninguna diferencia. Decidí crear un TestProject y descubrí que el mismo proceso se ejecutó en 4 segundos. Luego me di cuenta de que el proyecto estaba en modo de depuración y que el proyecto de prueba estaba en modo de lanzamiento. Cambié el proyecto principal al modo de lanzamiento y la lista completa de productos solo tardó 4 segundos en mostrar todos los resultados.
Resumen: el modo de depuración es mucho más lento que el modo de ejecución, ya que mantiene la información de depuración. Deberías desplegar siempre en modo Relase. Aún puede tener información de depuración si incluye archivos .PDB. De esta forma, puede registrar errores con números de línea, por ejemplo.
Una cosa que debe tener en cuenta, con respecto al rendimiento y si el depurador está conectado o no, algo que nos tomó por sorpresa.
Teníamos una pieza de código, que involucraba muchos bucles apretados, que parecía llevar una eternidad para depurar, pero que funcionó bastante bien por sí solo. En otras palabras, ningún cliente o cliente tenía problemas, pero cuando lo estábamos depurando parecía funcionar como melaza.
El culpable era un Debug.WriteLine en uno de los circuitos cerrados, que escupía miles de mensajes de registro, abandonados de una sesión de depuración hace un tiempo. Parece que cuando el depurador está conectado y escucha dicho resultado, hay una sobrecarga involucrada que ralentiza el programa. Para este código en particular, era del orden de 0,2-0,3 segundos de tiempo de ejecución por sí mismo, y más de 30 segundos cuando se adjuntó el depurador.
Solución simple, simplemente elimine los mensajes de depuración que ya no eran necesarios.