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!