Mejora del rendimiento al usar runat=server para controles html

Question

Intenté buscar esto en Google y me quedé un poco corto, así que tal vez alguien aquí pueda arrojar algo de luz sobre el tema.

Para fines de reescritura de URL en asp.net, me gustaría declarar todas las imágenes y otros recursos en mi aplicación con el atributo runat="server" para aprovechar la sintaxis de la ruta del servidor "~/images".La depuración en locahost es especialmente difícil cuando se utilizan rutas relativas (cuando se utiliza la reescritura de URL).Sé que puedo modificar los archivos host para solucionar un poco este problema, pero esto no es factible debido al volumen de proyectos en los que trabajamos.

Declarar controles html en el servidor runat normalmente aumentaría el estado de visualización para permitir la persistencia de datos, pero esto no sería relevante para las imágenes, ¿o me equivoco con respecto a esto...?

También me doy cuenta de que hay más controles para que el motor de ejecución de asp net los procese y maneje, pero ¿es esto realmente una pérdida grave de rendimiento...?

¿Existe una sobrecarga importante al declarar imágenes de esta manera? Si es así, ¿podría alguien explicar de dónde vendrá exactamente la mayor parte del impacto en el rendimiento?

Gracias de antemano.

Answer 1

Suponiendo que estás preguntando por las diferencias entre:

1) <img runat="server" EnableViewState="false" src="~/images/img.png" />

y

2) <img src='<%= ResolveUrl ("~/images/img.png") %>' />

Para construir 1), el código real generado (más o menos) es:

System.Web.UI.HtmlControls.HtmlImage __ctrl;
__ctrl = new System.Web.UI.HtmlControls.HtmlImage();
this._bctrl_1 = __ctrl;
__ctrl.EnableViewState = false;
__ctrl.Src = "~/image.png";

Luego ese __ctrl se agrega al árbol de control:

__parser.AddParsedSubObject(this._bctrl_1); // _bctrl_1 is __ctrl from above

Cualquier evento en el ciclo de vida de la página (Init, Load...) se propagará a este control, se llamará a RenderControl para obtener el HTML, se llamará a ResolveUrl() para obtener la URL real y, finalmente, Dispose() También será llamado.

Ahora, en el caso 2), el control no se agrega a su padre de la forma normal, sino que se obtiene algo como esto:

__ctrl.SetRenderMethodDelegate(new System.Web.UI.RenderMethod(this.__RenderTree));

Lo cual consiste en establecer un delegado al que se llamará cuando llegue el momento de representar el <img>.En __RenderTree la parte que escribe la etiqueta que nos interesa es:

__output.Write("\n<img src='");
__output.Write( ResolveUrl ("~/image.png") );
__output.Write("' />\n");

Entonces, sí, se ejecuta "mucho" código en 1) que no se ejecuta en 2).Ahora bien, en cuanto al impacto en el tiempo de ejecución real, creo que no es gran cosa.Probé una página vacía con nada más que la etiqueta/control img y la diferencia entre ellos en varias ejecuciones estuvo en el rango de -0,5 ms/+0,5 ms por solicitud. Totalmente insignificante.

Answer 2

Hay un significativo pariente Overhead incluso suponiendo que haya apagado todo el ViewState Marlarky. Sin embargo, el absoluto El costo probablemente sea inperceptible para un usuario individual.

Considere un marcado que describe una serie de elementos HTML, se trata como un simple "control" literal que envía de manera muy eficiente su contenido completo a la respuesta en el punto apropiado de la página.

Compare que se creen con los mismos elementos como controles completos con toda la creación de objetos, análisis del elemento de estilo, validación, etc. y la creación del estado local. Luego, el código se ejecuta para tomar el estado local y prácticamente representa el mismo marcado HTML utilizado para definirlo en la página ASP.NET en primer lugar.

Claramente, en términos de memoria y CPU, el uso de mucho runat = "servidor" va a ser más caro. En un caso individual, esto probablemente no sea un problema, pero para un sitio con actividad significativa podría ser.

Si está desarrollando una aplicación que se colocará en algún directorio virtual en un sitio más grande, use rutas relativas para sus imágenes.

Si está desarrollando una aplicación que está en un sitio propio, entonces en el proyecto o las propiedades del sitio, modifique la ruta virtual en la categoría de servidor web de desarrollador para que sea solo "/". De esa manera, al depurar no tienes el extra / myprojectName / parte en la URL. Esto le permitirá usar una ruta absoluta para algunos activos o carpetas de imágenes.