Estoy finalizando uno de mis proyectos y mirando todo el proyecto en busca de errores, errores y errores de rendimiento. Estoy usando MVC. Cogí uno No y eso es:¿Cuáles son algunos Desempeño [Qué hacer/Qué no hacer] en C# -ASP.NET
Nunca coloque un RenderPartial dentro de un bucle. ralentizará drásticamente todo tu servidor.
Nunca almacene un WebControl para la sesión.
Como tiene una referencia al objeto Page, termina almacenando cada control en la sesión.
Además, es un componente que pertenece a la página, por lo que si lo almacena en el estado de sesión y luego intenta usarlo en otra página, no funcionará correctamente. (He estado allí, hecho eso ...) :) – Guffa
Me gustaría agregar evitar el estado de sesión u otro estado global siempre que sea posible. No tanto por rendimiento, sino por mantenimiento general. – JohannesH
¿Ha ejecutado su programa a través de FxCop? Tiene un conjunto de reglas para el rendimiento.
No optimice prematuramente. :) Si el sitio no está funcionando, crea un perfil del código para determinar dónde pasar tu tiempo.
No perfile ni juzgue el rendimiento en la configuración de depuración. La configuración de depuración no pretende ser rápida, y puede hacer que las conclusiones de rendimiento sean incorrectas (como la idea de que vistas parciales/controles de usuario son lentos, esto es cierto en la configuración de depuración pero no en la configuración de lanzamiento). Cuando haga un perfil para medir el rendimiento, debe usar la configuración de lanzamiento para que pueda ver dónde están los problemas reales.
Muy, muy cierto. Además, no se olvide de publicar en modo de lanzamiento ;-) –
Utilice solo bloques de prueba/captura cuando sea necesario. Ellos ralentizan su aplicación.
EDITAR por Claridad: Por "necesario" me refiero, por detectar errores reales.
Si puede escribir un código y ser proactivo para asegurarse de que no se produzca el error, hágalo, ya que será más eficaz que dejar que se produzca una excepción, y luego manejarlo.
No utilice excepciones para controlar el flujo del programa. No sé quién lo dijo primero, pero recuerdo la frase "¡Las excepciones deben ser excepcionales!". Deben ser para los casos donde ocurren problemas imprevistos, cosas que no pudieron ser probadas antes de la ejecución del código y arrojándolos.
El peor ejemplo veo todo a menudo es algo a lo largo de estas líneas ...
int i = 0;
try
{
i = int.Parse(txt);
} catch {Exception x) {
// Do nothing, i = 0
}
Esta es, por supuesto, una versión específica de la regla más general "solo escriba el código que es necesario, el código innecesario ralentiza su aplicación". Averiguar qué líneas son "innecesarias" es la parte difícil. –
Solo hay un costo cuando se lanza una excepción. Un bloque try catch no tendrá ningún impacto en el rendimiento de tu código. – Charlie
Supongo que esto debería ser más "solo arrojar excepciones para el manejo de errores, nunca para el flujo de aplicación común y válido porque arrojar una excepción de hecho es costoso". – Alex
En C#, los objetos siempre se crean con uno nuevo. Esto solo puede ser un inconveniente en cierta perspectiva. Por ejemplo, si crea un objeto dentro de un bucle (lo que significa que se crea un nuevo objeto para cada iteración en el bucle) puede ralentizar su programa.
for (int i = 0; i < 1000; ++i)
{
Object o = new Object();
//...
}
En lugar de crear una instancia fuera del ciclo. Objeto o = new Object();
Object o = new Object();
for (int i = 0; i < 1000; ++i)
{
//...
}
Sólo crear un objeto en un bucle si realmente tiene que ...
Tal vez hacer un poco de C++ le ayudará a entender la mecánica detrás y saber cuándo y dónde optimizar el código. Aunque C++ es un idioma diferente, hay muchas cosas que puede aplicar a otros lenguajes una vez que comprenda los conceptos básicos de administración de memoria (nuevo, eliminar, punteros, matrices dinámicas/matrices estáticas, etc.).
Este es exactamente el tipo de optimización del rendimiento que uno debe evitar a menos que sea un problema . Muy a menudo, el código se hace mucho más complejo sin ninguna mejora en el rendimiento en absoluto. La gestión de memoria C++ es una historia completamente diferente ... – Alex
Dicho esto, crear objetos es muy, muy barato. Ayende perfiló esto: http://ayende.com/Blog/archive/2008/02/27/Creating-objects--Perf- Implications.aspx –
@Erik: si su clase realmente estuviera haciendo algunas operaciones serias, no sería tan barato;) @Alex: Para cada nuevo debe haber una eliminación en alguna parte ... en C# el recolector de basura hace la eliminación por ti. Dicho esto, si constantemente creas y destruyes objetos que están asignando mucha memoria o necesitas hacer ciertos trabajos ... ¡terminarás en un desastre! Si entiendes C++ lo entenderías. – Partial
La mayoría de los problemas de rendimiento se deben a acceso a disco o llamadas a través de redes.
Tenga en cuenta cómo y con qué frecuencia accede al sistema de archivos o a una base de datos. ¿Necesita hacer tantas llamadas en la red o podría hacerlo en una sola llamada?
Un buen ejemplo:
En este caso, una mejor solución puede escribir código personalizado para almacenar y leer el valor.
NO juguetee con la recolección de basura explícita.
almacenamiento en caché ayudaría a mejorar el rendimiento, sino que debe ser cuidadoso uso sólo cuando tenga sentido
NO utilizar los métodos estáticos - pero sólo si se utiliza con frecuencia el método.
no marca una variable estática a menos que realmente desea el valor de la variable a ser la misma en todos los casos (otro desarrollador hizo esto y me divertí depuración por eso que tenemos un comportamiento extraño cuando varios usuarios lleguen al sitio) Esto no es por motivos de rendimiento, sino solo como un buen consejo.
Lo que pasa con RenderPartial es * significativamente * más cierto en el modo de depuración que en el modo de lanzamiento. En modo de depuración, la sobrecarga es aplastante, ya que sondea para el ascx en cada iteración. En el modo de lanzamiento, esto se almacena en caché, por lo que generalmente no está nada mal. –