Algunos desarrolladores anteriores pusieron algunos ensamblajes que se construyeron en modo de depuración en producción. ¿Vale la pena recompilarlos en modo de lanzamiento y volver a implementarlos? Si solo hay un aumento de rendimiento del 1-2%, probablemente los deje allí. Por otro lado, un aumento del 10-20% podría cambiar mi opinión.¿Diferencia de rendimiento entre un ensamblado .NET integrado en modo depuración y versión?
Tuve la misma pregunta hace un año porque teníamos problemas importantes de rendimiento en la producción. Tal como me lo explicaron desde el soporte de MS Premier, las versiones de compilación de depuración incluyen ganchos para la depuración que pueden dar como resultado un aumento del 1 al 10% en el consumo de memoria dependiendo de lo que haga la aplicación.
Si no tiene problemas, déjelos en paz, pero si tiene problemas con el consumo de memoria, continúe y vuelva a compilar/implementar.
En mi experiencia, vi una diferencia de 30-40%. Esto fue con DotNetZip, una biblioteca que hace encriptación, compresión y un pequeño archivo de E/S. Más del 85% del tiempo se gastó en encriptación y compresión, solo moviendo bytes.
Otro argumento en contra del uso de compilaciones de depuración en producción es porque consumen mucha más memoria ya que se requieren cargar símbolos de depuración.
En general, verá un beneficio porque la versión de lanzamiento generalmente se compila con optimizaciones utilizando la opción del compilador /optimize. Sin embargo, cuán grande será la diferencia dependerá de su ensamblaje específico: necesitará un perfil.
Descubrí que la diferencia de rendimiento aumenta exponencialmente con la complejidad del código: una aplicación simple solo puede ver una diferencia del 5%, pero he visto hasta un 50% de ralentización en aplicaciones complejas, especialmente las que implican estructuras de datos más grandes como matrices o mapas.
Por supuesto, existe la posibilidad de que el código de depuración también sea ligeramente diferente, dependiendo de cómo esté configurado: consulte las aserciones, por ejemplo.
Vale la pena señalar que el código de liberación elimina también algunas cosas como preprocesador:
#if DEBUG
...
#endif
También elimina Debug.WriteLine, Debug.Assert, y algunas otras cosas en el espacio de nombres System.Diagnostics, que puede ser útil en las pruebas, pero no tienen sentido en el código bien diseñado para la versión de lanzamiento.
Si observa el código IL generado para las compilaciones de depuración y liberación, las diferencias son generalmente bastante pequeñas. La mayoría de las diferencias se encuentran en comandos nop adicionales en los puntos de origen clave para admitir la edición y la continuación y la depuración de la línea de origen. Sin embargo, cuando el tiempo de ejecución de .NET realmente JITs el MSIL, el ensamblaje del tiempo de ejecución es casi idéntico. La mayor diferencia se produce cuando se adjunta un depurador. Eso evitará que el JIT optimice el código de ejecución real.
Las versiones de lanzamiento son a menudo mucho más pequeñas porque simplemente no incluyen tanto código. Puede haber parches de código rodeados de instrucciones #de DEBUG y atributos condicionales que instruyen al compilador a omitir llamadas a métodos en modo de lanzamiento (Like Debug.WriteLine).
He encontrado que los métodos Debug.WriteLine y Trace.WriteLine, cuando se dejan en el código de producción y tienen implicaciones significativas de rendimiento incluso si no hay un depurador conectado.