Yes and no.
(Before I forget, I'm glad you brought this up. I remember reading about it a while back and wanted to give it a try, but forgot. =p)
If you write the same line of code in a compiled language and an interpreted language, the compiled language will always be faster. That's a fact... no getting around it. An interpreted language has an extra step where it has to read it and convert it to something that is compiled-like before it can act on it.
However, when you are dealing with ASP.NET and PHP explicitly, things get a little trickier.
Where I work, we actually have both running. We have a back-end developed by a third-party that uses Microsoft stuff, and thus ASP.NET. I'm our in-house developer and just about everything I do (web-based) is done in PHP.
Until recently, we had PHP running on Windows, using FastCGI. We also (obviously) had ASP.NET running in Windows.
I redid the portion of code which was PHP running on Windows (which was there because it had to be local to the ASP.NET for some interaction) to allow us to move it back to a Linux environment.
Before the move, when it was on Windows, the PHP was painfully slow. Once we moved it to Linux, it is now blazing fast (previously, the CPU would max out the CPU on the Windows system which had 8 cores and something to the order of 64+ gigs of RAM). On the Linux box, which has 4 cores and 8 gigs of RAM, it doesn't even go over .1% CPU usage (most of the time, it doesn't even go over .01%).
The ASP.NET does just fine on Windows, but runs steady at a few % CPU usage.
ASP.NET is compiled, and does some things faster. However, it also has a MUCH higher overhead cost (for example, ASP.NET has an AJAX Framework -Service- which runs on the server). This means you need a stronger machine to power the ASP.NET compared to PHP. Also, Windows (which ASP.NET requires) itself has more overhead than Linux.
This higher overhead somewhat offsets the difference in speed between the two (in most cases).
Also, when you say a "large application", you could be talking about several scenerios:
- A system which has many components, but most components are independent of one another for each particular page.
- A system which has one very large component which is run in most cases.
In the first case, even though there is a lot of code, only a fraction of it is being used at any one time, which you could (for this argument) consider as a collection of small applications. In this case, the boost in speed would be relatively minimal. This is the scenario which probably accounts for the vast majority of applications (and many that it doesn't apply to could probably be refactored to fit this scenario).
The other scenario, the one large component, is the situation in which compiled could greatly out-weight an interpreted language. In these cases, ASP.NET might have an edge of PHP. However, the overhead needed for ASP.NET is something that must be kept in mind.
There are also ways to offset the cost of a large component. For example, I've created a bit of code which lets me cache the output of parts of a PHP program which are common to all users. This lets me reduce the processing for each page somewhat (the actual amount varies greatly depending on the tasks being performed, but could be between 5-99% in some cases).