Performance Knock On Utilisation de Runat = Server pour les contrôles HTML

Question

J'ai essayé de Google et est venu un peu court, alors peut-être que quelqu'un ici peut faire la lumière sur le sujet.

À des fins de réécriture d'URL dans ASP.NET, je voudrais déclarer toutes les images et autres ressources de mon application avec l'attribut runat = "server" pour profiter de la syntaxe du chemin du serveur "~ / / images". Le débogage sur Locahost est particulièrement difficile lorsque des chemins relatifs sont utilisés (lors de l'utilisation de la réécriture de l'URL). Je sais que je peux modifier les fichiers hôtes pour surmonter quelque peu ce problème, mais ce n'est pas possible en raison du volume de projets sur lesquels nous travaillons.

Déclarer les contrôles HTML au serveur Runat ajouterait normalement au ViewState pour permettre la persistance des données, mais cela ne serait pas pertinent pour les images, ou suis-je confondu en ce qui concerne cela ...?

Je me rends également compte qu'il y a plus de contrôles pour le moteur d'exécution ASP Net pour traiter et gérer, mais est-ce vraiment un drain de performance sérieux ...?

Y a-t-il un aérien sérieux dans la déclaration des images de cette manière, et si oui, quelqu'un pourrait-il expliquer d'où vient exactement la majeure partie du coup de performance.

Merci d'avance.

Answer 1

En supposant que vous demandez les différences entre:

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

et

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

Pour construire 1), le code réel généré (plus ou moins) est:

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

Ensuite, ce __ctrl est ajouté à l'arbre de commande:

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

Tout événement dans le cycle de vie de la page (init, chargement ...) sera propagé à ce contrôle, RenderControl sera appelé pour en tirer le HTML, ResolveUrl () est appelé pour obtenir l'URL réelle et, enfin, disposer () sera appelé aussi.

Maintenant, dans le cas 2), le contrôle n'est pas ajouté à son parent de la manière normale, mais à la place, vous obtenez quelque chose comme ceci:

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

Qui définit un délégué qui sera appelé quand il est temps de rendre leu003Cimg> . Dans __RenderTree, la partie qui écrit la balise qui nous intéresse est:

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

Donc, oui, il y a "beaucoup" de code exécuté en 1) qui n'est pas exécuté en 2). Maintenant, en ce qui concerne l'impact du temps d'exécution réel, je pense que ce n'est pas si important. J'ai testé une page vide avec rien d'autre que la balise / contrôle IMG et la différence entre eux dans plusieurs exécutions était dans la plage de -0,5 ms / + 0,5 ms par demande. Totalement négligeable.

Answer 2

Il y a un important relatif Au-dessus, en supposant même que vous avez désactivé tout le Viewstate Marlarky. Cependant, le absolu Le coût est probablement perceptible pour un utilisateur individuel.

Considérez un balisage décrivant une série d'éléments HTML, il est traité comme un simple "contrôle" littéral qui envoie très efficacement son contenu entier à la réponse au point approprié du rendu de la page.

Comparez cela avec tous les mêmes éléments créés en tant que contrôles complets avec toute la création d'objets, l'analyse de l'élément de style, la validation, etc. et la création de l'état local. Ensuite, le code s'exécute pour prendre l'état local et rendre à peu près le même balisage HTML utilisé pour le définir dans la page ASP.NET en premier lieu.

De toute évidence, en termes de mémoire et de processeur, l'utilisation de beaucoup de runat = "server" va plus cher. Dans un cas individuel, ce n'est probablement pas un problème, mais pour un site avec une activité importante, cela pourrait bien l'être.

Si vous développez une application qui sera placée dans un répertoire virtuel dans un site plus grand, utilisez des chemins relatifs pour vos images.

Si vous développez une application qui se trouve sur un site à part, dans les propriétés du projet ou du site, modifiez le chemin virtuel de la catégorie du serveur Web du développeur pour être juste "/". De cette façon, lors du débogage, vous n'avez pas le nom supplémentaire / myprojectname / partie de l'URL. Cela vous permettra d'utiliser un chemin absolu vers certains actifs ou un dossier d'images.