Leistung klopft auf Runat = Server für HTML -Steuerelemente

Question

Ich habe versucht, das zu googeln und kam ein wenig kurz, also kann hier jemand hier etwas Licht in das Thema werfen.

Für URL -Umschreibungszwecke in ASP.NET möchte ich alle Bilder und anderen Ressourcen in meiner Anwendung mit dem Attribut runat = "Server" deklarieren, um die Serverpfad -Syntax "~/Images" zu nutzen. Das Debuggen auf Locahost ist besonders schwierig, wenn relative Pfade verwendet werden (bei der Verwendung von URL -Umschreiben). Ich weiß, dass ich die Hostdateien so ändern kann, dass dieses Problem etwas überwunden wird, aber dies ist aufgrund des Projekts der Projekte, an denen wir arbeiten, nicht möglich.

Das Deklarieren von HTML -Steuerelementen an Runat -Server würde normalerweise zum ViewState hinzufügen, um die Datenpersistenz zu ermöglichen. Dies wäre jedoch nicht für Bilder relevant, oder bin ich in Bezug auf diese ...?

Mir ist auch klar, dass es mehr Steuerelemente für die ASP -Net -Laufzeit -Engine gibt, um zu verarbeiten und zu handhaben, aber ist dies wirklich ein ernsthafter Leistungsabfluss ...?

Gibt es einen ernsthaften Aufwand, um Bilder auf diese Weise zu deklarieren, und wenn ja, könnte jemand erklären, woher genau der Großteil des Leistungsschlags kommt?

Danke im Voraus.

Answer 1

Assuming that you are asking for the differences between:

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

and

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

To build 1), the actual code generated (more or less) is:

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

Then that __ctrl is added to the control tree:

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

Any event in the page lifecycle (Init, Load...) will be propagated to this control, RenderControl will be called to get the HTML from it, ResolveUrl() is called to get the actual URL, and, finally, Dispose() will be called too.

Now, in case 2), the control is not added to its parent the normal way, but instead you get something like this:

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

Which is setting a delegate that will be called when its time to render the <img>. In __RenderTree the part that writes the tag we're interested in is:

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

So, yes, there's "a lot" of code being run in 1) that is not run in 2). Now, as far as the impact in actual execution time I think this is not that big of a deal. I tested an empty page with nothing but the img tag/control and the difference between them in several runs was in the range of -0.5ms/+0.5ms per request. Totally negligible.

Answer 2

There is a significant relative overhead even assuming you've turned off all the viewstate marlarky. However the absolute cost is probably inperceptible to an individual user.

Consider a markup describing a series of HTML elements, It is treated as a simple literal "control" which very efficiently sends its entire contents to the response at the appropriate point in the page render.

Compare that with all the same elements being created as full controls with all the object creation, parsing of style element, validation etc and creation of local state. Then code runs to take the local state and pretty much render the same HTML markup used to define it in the ASP.NET page in the first place.

Clearly in terms of memory and CPU using a lot of runat="server" is going to more expensive. In an individual case this is probably not an issue but for a site with significant activity it could well be.

If you are developing an application which will be placed in some virtual directory in a larger site then use relative paths for your images.

If you are developing an application which is to a site of its own then in the project or site properties modify the Virtual path in the Developer Web Server category to be just "/". That way when debugging you don't have the extra /myprojectname/ part in the URL. This will allow you use an absolute path to some assets or images folder.