Common ASP .NET performance myths
In an MSDN article, Rob Howard writes about some of the most common performance myths with regards to ASP .net:
1. C# code runs faster than VB .NET.
Not true.
Rob Howard: similar code produces similar results.
Me: however, there is generally a higher respect paid to C#.
2. Code behind faster than inline script.
Absolutely false
Rob Howard: Sometimes I prefer to use inline code as changes don't incur the same update costs as codebehind. For example, with codebehind you have to update the entire codebehind DLL, which can be a scary proposition.
Me: Codebehind has better intellisense support and does make the code cleaner.
3. Components are faster than pages
False.
Rob Howard: Organizationally, it is better to group functionality logically this way, but again it makes no difference with regard to performance.
Me: Ditto.
4. Every functionality that you want to occur between two apps should be implemented as a Web service.
???
Rob Howard: Web services should be used to connect disparate systems or to provide remote access to system functionality or behaviors. They should not be used internally to connect two similar systems. While easy to use, there are much better alternatives. The worst thing you can do is use Web services for communicating between ASP and ASP.NET applications running on the same server, which I've witnessed all too frequently.
My take: There are also better and lighter alternatives that Web services. Also, there are web services that provide XML data over HTTP, in a lightweight approach sometimes referred to as REST (Representational State Transfer), and there are also heavy set web services using the SOAP (Simple Object Access Protocol) web services stack. The former has achieved a greater success and popularity, for example, Google, Yahoo, Amazon ...