Search code examples
asp.netperformancerunatserver

Performance knock on using runat=server for html controls

I tried to google this and came up a little short, so maybe someone here can shed some light on the topic.

For url rewriting purposes in asp.net, I would like to declare all images and other resources in my application with the runat="server" attribute to take advantage of the "~/images" server path syntax. Debugging on locahost is especially difficult when relative paths are used (when using url rewriting). I know I can modify the host files to somewhat overcome this problem, but this is not feasible due to the volume of projects we work on.

Declaring html controls to runat server would normally add to the viewstate to enable data persistence, but this would not be relevant to images, or am I mistaken with regards to this...?

I also realise that there are more controls for the asp net runtime engine to process and handle, but is this really a serious performance drain...?

Is there a serious overhead in declaring images in this manner, and if so, could someone explain where exactly the bulk of the performance knock will come from.

Thanks in advance.

Solution

  • 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.