To expand on the topic started in my previous post, here is an overview on how ASP.NET compiles and recompiles assemblies. 

You all know that when you initially make an .aspx page and run it, the application is started and your stuff is compiled into cached assemblies stored by default in C:WINNTMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files#AppName#.  If you keep Win Explorer open to that directory while you restart your app, you’ll see the new temporary files appear as the app is compiled for the first time.  Then for every subsequent request, those files don’t change.  Then change ANYTHING in an .aspx file (even just one character in the markup).  Actually, you don’t have to change anything, just save it again.  As soon as you save it, the cached assembly for that page will be invalidated, and when you hit the page with the browser again, it will be recompiled, and you will see new files pop up, and the old ones will have “.delete” appended.  On the next app restart, the .delete files will be purged.  So to clarify my previous post, ASP.NET does NOT check for changes on every page hit.  It checks for a cached assembly and uses it if it exists.  When a file is saved, the cached assembly is invalidated, so when the page is requested, it doesn’t find a valid assembly, so it must compile it. 

So regarding the previous post, whether you use inline code, code-behind, code-beside, base page inheritence, or a mixture of all of them, the page compilation will have the same behavior, and the request lifecycle will also be the same.  There is no performance difference based on the method in which you code.