I recently had an interesting discussion over lunch with a colleague about the performance of in-line code versus the code-behind model. I relayed that I prefer to put the small, UI-related code in a <script runat=”server”/> block in the .aspx file, and my colleague swore by the code-behind model. I currently use the code-behind model because intellisense makes development so much faster, but every time I want to make a small change to the UI that involves som C#, I have to fire up VS.NET and then build the whole project. For my corporate projects I do this anyway because the of the source control, but not all projects need this. My colleague insisted that script block incur and extra performance hit because the ASP.NET engine must check for changes in every page hit. After lunch, I whipped up a test and created to ASP.NET pages: one with code-behind, and the other with the code in a script block. I ran each for 1 minute in WAST. Then I ran each 8 more times. My results: It doesn’t make a hill of beans difference. Each test was less than 1% difference. Some tests the code-behind was less and 1% faster and some resulted in the in-line code being less than 1% faster. Averaging all the tests gave the same performance for both methods. So now I know first-hand that it doesn’t matter architecturally. It’s only personal and team preference. Now, don’t take this as an excuse for putting a lot of code in your .aspx page. If you choose to do that, it should only be UI event handlers. All REAL code should be in your business objects. Use this knowledge responsibly!
From MSDN, ASP.Net Common Performance Myths: http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/default.aspx?side=true
Steve, I think you meant to say "replace Codebehind= with src= ". Inherits= must be used with src=.
Explanation of dynamic ASPX compilation and recompilation – level 300
In your post, you stated… "every time I want to make a small change to the UI that involves som C#, I have to fire up VS.NET and then build the whole project"
In your <%@ Page … %> tag, you can replace Inherits= with src= to get around this. This means you have to distribute your C# code, but there is the workaround if you need it.
If you want a rundown on what’s happening on code-behind vs. in-script, check out Chapter 1 on Essential ASP.NET by Fritz Onion. You’ll understand exactly why there is no difference and then you can hand it to your buddy.
Then I’d run the following code:
colleague.SpeaksFromSphincter = true;
::My colleague insisted that script block
::incur and extra performance hit because the
::ASP.NET engine must check for changes in
::every page hit
Tell your colleague McDonalds ahs a job for him – serviung burgers. He is better qualified for this than programming.
* ASP.NET never checks for changes. ASP.NET subscribes to the events in the file system. When ANY file is changed, ASP.NET is notified and restarts the app.
* Even with codebehind, a change in an ASP.NET page – any change – has to trigger a recompilation. Why? New server side objects may be in there etc.
Common sense, oh so rare today.
Besides, this is pretty basic knowledge, properly documented in the documentation and thoroughly discussed in every message board.