Whenever I tell other .NET developers I prefer VB over C# (which wasn't the case until this past February), user controls are glorified server-side include files, and migrating a classic ASP site to .NET can be done with less pain than everyone wants you to believe, I get a dirty look or two.  Sure, things have changed in regards to best practices and performance, but most of the performance issues are myths.  Yanghaifeng's blog entry cites discusses these myths Rob Howard presented in his 10 Tips for Writing High-Performance Web Applications article on MSDN.

One of the most common myths  is that C# code is faster than Visual Basic code. There is a grain of truth in this, as it is possible to take several performance-hindering actions in Visual Basic that are not possible to accomplish in C#, such as not explicitly declaring types. But if good programming practices are followed, there is no reason why Visual Basic and C# code cannot execute with nearly identical performance. To put it more succinctly, similar code produces similar results.

Note: in fact, both C# and VB.NET will be converted to IL and executed on CLR environment, it's totally the same.

Another myth is that code-behind is faster than inline, which is absolutely false. It doesn't matter where your code for your ASP.NET application lives, whether in a code-behind file or inline with the ASP.NET page. Sometimes I prefer to use inline code as changes don't incur the same update costs as code-behind. For example, with code-behind you have to update the entire code-behind DLL, which can be a scary proposition.

Note: both inline code and code behind code will be compiled to one page class and executed in HTTPModule.

Myth number three is that components are faster than pages. This was true in Classic ASP when compiled COM servers were much faster than VBScript. With ASP.NET, however, both pages and components are classes. Whether your code is inline in a page, within a code-behind, or in a separate component makes little performance difference. Organizationally, it is better to group functionality logically this way, but again it makes no difference with regard to performance.