Common ASP .NET performance myths

Published Friday, March 07, 2008 9:21 PM


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


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 ...


# said on Friday, March 07, 2008 1:38 PM

You've been kicked (a good thing) - Trackback from

# sirrocco said on Friday, March 07, 2008 2:29 PM

How about giving some examples for number 4.

# Bart Czernicki said on Friday, March 07, 2008 3:22 PM

LOL...I love the last one "web services".  I am not big on semantics, but web services are an implmentation of SOA.  I hate when people say that.  WCF -> WCF communication over netTCP binding isn't going to be that "slow".

Second, yes from a strict performance perspective say u have one server and u use a service to bridge ur db and UI its going to be a penalty.  Let me ask you this?  Say u are running a website that is rapidly growing and now u need 3 servers?  What is easier to scale? DB/Services/Web Server or DB/BLL Assemblies/Web Server?  Your 2nd tier services now automatically can scale up to another server so u have a server for each layer (which probably includes ur caching code).

"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."

This is why u don't base ur architecture off of blogs, because the statement above is very easily challenged.

# xxxd said on Sunday, March 09, 2008 11:56 AM

First I admit that I am no performance guru.

Second I have to say you probably are right about services vs bll assemblies with regards to scalabilty.

I think the key word here is "EVERY" functionality. One big principal is never say "Yes" to "Every". Because every problem is unique, every application merries its own analysis and solution.

The other key words are difference of application types, distances (remote, mulitple servers vs single server), and ownship of web hosts.

This site

This Blog



  • MaximumASP