Related
I know you can minify PHP, but I'm wondering if there is any point. PHP is an interpreted language so will run a little slower than a compiled language. My question is: would clients see a visible speed improvement in page loads and such if I were to minify my PHP?
Also, is there a way to compile PHP or something similar?
PHP is compiled into bytecode, which is then interpreted on top of something resembling a VM. Many other scripting languages follow the same general process, including Perl and Ruby. It's not really a traditional interpreted language like, say, BASIC.
There would be no effective speed increase if you attempted to "minify" the source. You would get a major increase by using a bytecode cache like APC.
Facebook introduced a compiler named HipHop that transforms PHP source into C++ code. Rasmus Lerdorf, one of the big PHP guys did a presentation for Digg earlier this year that covers the performance improvements given by HipHop. In short, it's not too much faster than optimizing code and using a bytecode cache. HipHop is overkill for the majority of users.
Facebook also recently unveiled HHVM, a new virtual machine based on their work making HipHop. It's still rather new and it's not clear if it will provide a major performance boost to the general public.
Just to make sure it's stated expressly, please read that presentation in full. It points out numerous ways to benchmark and profile code and identify bottlenecks using tools like xdebug and xhprof, also from Facebook.
2021 Update
HHVM diverged away from vanilla PHP a couple versions ago. PHP 7 and 8 bring a whole bunch of amazing performance improvements that have pretty much closed the gap. You now no longer need to do weird things to get better performance out of PHP!
Minifying PHP source code continues to be useless for performance reasons.
Forgo the idea of minifying PHP in favor of using an opcode cache, like PHP Accelerator, or APC.
Or something else like memcached
Yes there is one (non-technical) point.
Your hoster can spy your code on his server. If you minify and uglify it, it is for spys more difficult to steal your ideas.
One reason for minifying and uglifying php may be spy-protection. I think uglyfing code should one step in an automatic deployment.
With some rewriting (shorter variable names) you could save a few bytes of memory, but that's also seldomly significant.
However I do design some of my applications in a way that allows to concatenate include scripts together. With php -w it can be compacted significantly, adding a little speed gain for script startup. On an opcode-enabled server this however only saves a few file mtime checks.
This is less an answer than an advertisement. I'm been working on a PHP extension that translates Zend opcodes to run on a VM with static typing. It doesn't accelerate arbitrary PHP code. It does allow you to write code that run way faster than what regular PHP allows. The key here is static typing. On a modern CPU, a dynamic language eats branch misprediction penalty left and right. Fact that PHP arrays are hash tables also imposes high cost: lot of branch mispredictions, inefficient use of cache, poor memory prefetching, and no SIMD optimization whatsoever. Branch misprediction and cache misses in particular are achilles' heel for today's processors. My little VM sidesteps those problem by using static types and C array instead of hash table. The result ends up running roughly ten times faster. This is using bytecode interpretation. The extension can optionally compile a function through gcc. In that case, you get two to five times more speed.
Here's the link for anyone interested:
https://github.com/chung-leong/qb/wiki
Again, the extension is not a general PHP accelerator. You have to write code specific for it.
There are PHP compilers... see this previous question for a list; but (unless you're the size of Facebook or are targetting your application to run client-side) they're generally a lot more trouble than they're worth
Simple opcode caching will give you more benefit for the effort involved. Or profile your code to identify the bottlenecks, and then optimise it.
You don't need to minify PHP.
In order to get a better performance, install an Opcode cache; but the ideal solution would be to upgrade your PHP to the 5.5 version or above because the newer versions have an opcode cache by default called Zend Optimiser that is performing better than the other ones http://massivescale.blogspot.com/2013/06/php-55-zend-optimiser-opcache-vs-xcache.html.
The "point" is to make the file smaller, because smaller files load faster than bigger files. Also, removing whitespace will make parsing a tiny bit faster since those characters don't need to be parsed out.
Will it be noticeable? Almost never, unless the file is huge and there's a big difference in size.
I was surprised to learn today that PHP is used widely in high-traffic websites.
I always thought that PHP is not strong in terms of performance, being a dynamic, scripting language (e.g. compared to statically typed, compiled language like C/Java/C# etc.).
So how come it performs so well?
What you'll usually find is that it's not as slow as you think. The reason a lot of sites are slow is because the hosts are overloaded.
But one primary benefit of PHP over a compiled language is ease of maintenance. Because PHP is designed from the ground up for HTTP traffic, there's less to build than with most other compiled languages. Plus, merging in changes becomes easier as you don't need to recompile and restart the server (as you would with a compiled binary)...
I've done a considerable amount of benchmarks on both, and for anywhere under about 50k requests per second (based upon my numbers) there really isn't a significant gain to using a compiled binary (FastCGI). Sure, it's a little faster using compiled C, but unless you're talking Facebook level traffic, that's not really going to mean significant $$$. And it's definitely not going to offset the relatively rapid rate of development that PHP will afford in comparison to using C (which more than likely will require many times the code since it's not memory managed)...
PHP, if properly written can be quite scalable. The limiting factors are typically in your database engine. And that's going to be a common factor no matter what technology you use...
Java deployments in a big enterprise setting are a mess...fighting with builds and code that might not compile for the slightest little things. Also, PHP runs on a fairly simple setup server-wise, not the bulky code that is Weblogic (or others), so others are right in that it's low cost to develop and cheap to deploy on several different machines. It certainly didn't help that I was soured by working in a large, VERY inefficient corporate setting while doing Java....
I wouldn't say that PHP developers are cheaper per se (I make more now as a PHP developer than I did as a Java UI developer) but I do know that my last employer paid me for a not-insignificant amount of time spent configuring, deploying, compiling, etc that is not required in PHP. We're talking probably one day/week of related configuration fussing due to new branch roll outs or release-related configurations. So, the extra I'm paid now is made up for by a significant amount more code that I'm able to work through each week.
PHP is certainly being helped by the fact that MySQL and Postgres (to a smaller extent) have become so much more powerful. They're not directly linked, but having that as a common pairing just sweetens the deal for those making decisions.
It doesn't really perform "so well", just well enough to be used. Keep in mind, though, that Java and C#.NET are also run as bytecode inside a VM. PHP, with tools such as Zend Optimizer, can also skip the compilation step and run as bytecode.
PHP will not run as fast as native, compiled C code, but websites such as Facebook compile PHP to C++ to make it run faster (see HipHop-PHP).
Most websites have performance bottle necks when querying a database etc. The amount of time the script spends executing is usually small compared to this. Using things like libmemcached can help mitigate this.
Many sites started as low-traffic sites. Once you have your PHP website running and suddenly you have to handle much higher traffic, it's cheaper just to buy more servers than to rewrite your app from PHP to something else. Moreover there are tools that improve PHP performance.
Also note, that there are other factors: database, caching strategy which affect performance more than PHP itself.
It doesn't, which is why there are projects like HipHop, but dynamic languages are often faster to develop in, and hardware is cheaper than developers.
In my opinion the stateless nature of PHP is the most important factor to it's scalability. It's been a while since I've done any web work with Java/ASP.NET, but I recall that both technologies have a central application "engine" that all requests are piped through. That's great, because information and state can be shared between instances, and a lot of bootstrapping (reading configuration files, connecting to databases, etc) can be done once, and then shared among instances. It's bad though because that central "engine" itself becomes a bottleneck for the whole application.
The lack of a central engine in PHP also means scaling your application is usually a simple matter of adding another web server to your rig (although scaling the database along with it is more complicated). I imagine scaling a Java/ASP.NET application is a good deal more complicated, and they reach a saturation point where adding more hardware gives less of a boost each time.
This is something I've always wondered: Why is PHP slower than Java or C#, if all 3 of these languages get compiled down to bytecode and then executed from there? I know that normally PHP recompiles each file with each request, but even when you bring APC (a bytecode cache) into the picture, the performance is nowhere near that of Java or C# (although APC greatly improves it).
Edit:
I'm not even talking about these languages on the web level. I am talking about the comparison of them when they're number crunching. Not even including startup time or anything like that.
Also, I am not making some kind of decision based on the replies here. PHP is my language of choice; I was simply curious about its design.
One reason is the lack of a JIT compiler in PHP, as others have mentioned.
Another big reason is PHP's dynamic typing. A dynamically typed language is always going to be slower than a statically typed language, because variable types are checked at run-time instead of compile-time. As a result, statically typed languages like C# and Java are going to be significantly faster at run-time, though they typically have to be compiled ahead of time. A JIT compiler makes this less of an issue for dynamically typed languages, but alas, PHP does not have one built-in. (Edit: PHP 8 will come with a built-in JIT compiler.)
I'm guessing you are a little bit into the comparing of apples and oranges here - assuming that you are using all these languages to create web applications there is quite a bit more to it than just the language. (And lots of the time it is the database that is slowing you down ;-)
I would never suggest choosing one of these languages over the other on the basis of a speed argument.
Both Java and C# have JIT compilers, which take the bytecode and compile into true machine code. The act of compiling it can take time, hence C# and Java can suffer from slower startup times, but once the code is JIT compiled, its performance is in the same ballpark as any "truly compiled" language like C++.
The biggest single reason is that Java's HotSpot JVM and C#'s CLR both use Just-In-Time (JIT) compilation. JIT compilation compiles the bytecodes down to native code that runs directly on the processor.
Also I think Java bytecode and CIL are lower-level than PHP's internal bytecode which might make alot of JIT optimizations easier and more effective.
A wild guess might be that JAVA depends on some kind of "application" server, while PHP doesn't -- which means a new environnement has to be created each time a PHP page is called.
(This was especially true when PHP was/is used as a CGI, and not as an Apache module or via FastCGI)
Another idea might be that C# and JAVA compilers can do some heavy optimisations at compile time -- on the other side, as PHP scripts are compiled (at least, if you don't "cheat" with an opcode cache) each time a page is called, the compilation phase has to be real quick ; which means it's not possible to spend much time optimizing.
Still : Each version of PHP generally comes with some amelioration of the performances ; for instance, you can gain between 15% and 25% of CPU, when switching from PHP 5.2 to 5.3.
For instance, take a look at those benchmarks :
Benchmark of PHP Branches 3.0 through 5.3-CVS
Performance PHP 5.2 vs PHP 5.3 - huge gain
Bench PHP 5.2 vs PHP 5.3 -- disclaimer : it's in french, and I'm the one who did it.
One important thing, also, is that PHP is quite easy to scale : just add a couple of web servers, and voila !
The problem you often meet when going from 1 to several servers is with sessions -- store those in DB or memcached (very easy), and problem solved !
As a sidenote : I would not recommend choosing a technology because there is a couple of percent difference of speed on some benchmark : there are far more important factors, like how well your team know each technology -- or, even, the algorithms you are going to use !
There is no way an interpreted language can be faster than a compiled language or even a JIT language under trivial conditions.
Unless your test program consists of printing out "Hello Worlds" if you are concerned about speed, stick with C# or Java.
Depends on what you want to do. In some cases, PHP is definitely faster. PHP is (pretty) good at file manipulation and other basic stuff (also XML stuff). Java or C# might be slower in those cases (though I didn't benchmark).
Also, the PHP output (HTML or whatever) needs to be downloaded to the browser, which also consumes time.
Also, the speed of Java / C# is very much depending on the machine it runs on (which could be multiple). Java / C# could be slow on your computer, while PHP just runs on one server from which it is available and is always as fast as the server is (except for download times, etc.).
I don't think they are comparable in a general manner. I think you need to take a task, which you could be accomplished with those three programming languages, and then compare that. That is basically always what you should do when choosing a programming language; find the one that fits the task. Don't shape the task until it fits the programming language.
According to wikipedia, PHP uses The Zend Engine, which does not have a JIT.
If I write a hello world app using a PHP web framework such as CodeIgniter and then I compile it and run it using HipHop. Will it run faster than if I write the same hello world app in django or rails?
HIPHOP converts php code into C++ code, which needs to be compiled to run. Since pre-compiled code runs faster and uses less memory then scriping languages like python/php it will probably run faster in the example you have given.
However, HIPHOP does not convert all code. A lot of code in php is dynamic and can not be changed to c++, this means you will have to write your code with this in mind. If codeigniter can even be compiled using HIPHOP is another question.
Terry Chay wrote a big article about HIPHOP, covering when to use it, it's limitations and future. I would recomment reading this, as it will most likely answer most of your questions and give you some insight into how it works :)
http://terrychay.com/article/hiphop-for-faster-php.shtml
At that point the run time is inconsequential. HipHop was designed for scaling... meaning billions of requests. There's absolutely no need to use something like HipHop for even a medium size website.
But more to the point of your question... I don't think there have been comparison charts available for us to see, but I doubt the run time would be faster at that level.
i don't know about django or rails, so this is a bit off-topic.
with plain php, the request goes to apache, then to mod_php. mod_php loads the helloworld.php script from disk, parses & tokenizes it, compiles it to bytecode, then interprets the bytecode, passes the output back to apache, apache serves it to the user.
with php and an optimizer the first run is about the same as with plain php, but the compiled source code is stored in ram. then, for the second request: goes to apache, apache to mod_php, apc loads bytecode from ram, interprets it, passes it back to apache, back to the user.
with hiphop there is no apache, but hiphop itself and there's no interpreter, so request goes directly to hiphop and back to the user. so yes, it's faster, because of several reasons:
faster startup because there's no bytecode compilation needed - the program is already in machine-readable code. so no per-request compilation and no source file reading.
no interpreter. machine code is not necessarily faster - that depends on the quality of source translation (hiphop) and the quality of the static compiler (g++). hiphop translated code is not fast compared to hand-written c code, because there's a bit of overhead because of type handling and such.
with node.js, there's also no apache. the script is started and directly compiled to machine code (because the V8 compiler does that), so it's kind of AOT (ahead of time) compiling (or is it still called JIT? i don't really know). every request is then directly handled by the already compiled machine code; so node.js is actually very comparable to hiphop. i assume hiphop to be multithreaded or something like this, while node does evented IO.
facebook claims a 50% speed gain, which is not really that much; if you compare the results of the language shootout, you'll see for the execution speed of assorted algorithms, php is 5 to 250 times slower.
so why only 50%? because ...
web apps depend on much more than just execution speed, e.g. IO
php's type system prevents hiphop to make the best use of c++'s static types
in practice, a lot of php is already C, because most of the functionality is either built in or comes from extensions. extensions are programmed in C and statically compiled.
i'm not sure if there was a huge performance gain for hello world, because hello world, even with a good framework, is still so small execution speed could be negligible in comparison to all the other overhead (network latency and stuff).
imo: if you want speed and ease of use, go for node.js :)
Running a simple application is always faster in any language. When it's become as complex as facebook, then you will face numerous of problems. PHP slowness will be show it's face. In same times, converting existing code to another language is not an options, since all logic and code is not so easy to translated to other language's syntax. That's why facebook developer decide to keep the old code, and make PHP faster. That's the reason they create their own PHP compiler, called HipHop.
Read this story from the perspective one of Facebook developer, so you know the history of HipHop.
That is not really an apple to apples comparison. In the most level playing field you might have something like:
Django running behind apache
Django rendering an HTML template to say hello world (no caching)
AND
HPHP running behind apache
HPHP rendring an HTML template to say hello world (again, no caching)
There is no database, almost no file I/O, and no caching. If you hit the page 10,000 times with a load generator at varying concurrency levels you will probably find that HPHP will outperform Django or rails - that is to say it can serve render more pages per second and keep up with your traffic a bit better.
The question is, will you ever have this many concurrent users? If you will, will they likely be hitting a database or a cached page?
HPHP sounds cool, but IMHO there is no reason to jump ship just yet (unless you are getting lots of traffic, in which case it might make sense to check it out).
Will it run faster than if I write the
same hello world app in django or
rails?
It probably will, but don't fret. If we're talking prospective speed improvements from yet unreleased projects, Pythonistas have pypy-jit and unladen-swallow to look forward to ;)
I have a friendly argument going on with a co-worker about this, and my personal opinion is that a ASP.NET-MVC compiled web application would run more efficiently/faster than the same project that would be written in PHP. My friend disagrees.
Unfortunately I do not have any solid data that I can use to back up my argument. (neither does he)
To this, I tried to Google for answers to try and find evidence to prove him wrong but most of the time the debate turned into which platform it is better to develop on, cost, security features, etc... For the sake of this argument I really don't care about any of that.
I would like to know what stack overflow community thinks about the raw speed/efficency of websites in general that are developed in ASP.NET with MVC versus exactly the same website developed with PHP?
Does anyone have any practical examples in real-world scenarios comparing the performance of the two technologies?
(I realize for some of you this may very well be an irrelevant and maybe stupid argument, but it is an argument, and I would still like to hear the answers of the fine people here at S.O.)
It's a hard comparison to make because differences in the respective stacks mean you end up doing the same thing differently and if you do them the same for the purpose of comparison it's not a very realistic test.
PHP, which I like, is in its most basic form loaded with every request, interpreted and then discarded. It is very much like CGI in this respect (which is no surprise considering it is roughly 15 years old).
Now over the years various optimisations have been made to improve the performance, most notably opcode caching with APC, for example (so much so that APC will be a standard part of PHP 6 and not an optional module like it is now).
But still PHP scripts are basically transient. Session information is (normally) file based and mutually exclusive (session_start() blocks other scripts accessing the same user session until session_commit() or the script finishes) whereas that's not the case in ASP.NET. Aside from session data, it's fairly easy (and normal) to have objects that live within the application context in ASP.NET (or Java for that matter, which ASP.NET is much more similar to).
This is a key difference. For example, database access in PHP (using mysql, mysqli, PDO, etc) is transient (persistent connections notwithstanding) whereas .Net/Java will nearly always use persistent connection pools and build on top of this to create ORM frameworks and the like, the caches for which are beyond any particular request.
As a bytecode interpreted platform, ASP.NET is theoretically faster but the limits to what PHP can do are so high as to be irrelevant for most people. 4 of the top 20 visited sites on the internet are PHP for example. Speed of development, robustness, cost of running the environment, etc... tend to be far more important when you start to scale than any theoretical speed difference.
Bear in mind that .Net has primitive types, type safety and these sorts of things that will make code faster than PHP can run it. If you want to do a somewhat unfair test, sort an array of one million random 64 bit integers in both platforms. ASP.NET will kill it because they are primitive types and simple arrays will be more efficient than PHP's associative arrays (and all arrays in PHP are associative ultimately). Plus PHP on a 32 bit OS won't have a native 64 bit integer so will suffer hugely for that.
It should also be pointed out that ASP.NET is pre-compiled whereas PHP is interpreted on-the-fly (excluding opcode caching), which can make a difference but the flexibility of PHP in this regard is a good thing. Being able to deploy a script without bouncing your server is great. Just drop it in and it works. Brilliant. But it is less performant ultimately.
Ultimately though I think you're arguing what's really an irrelevant detail.
ASP.NET runs faster. ASP.NET Development is faster.
Buy fast computer, and enjoy it if you do serious business web applications
ASP.NET code executes a lot faster compared to PHP, when it's builded in Release mode, optimized, cached etc etc. But, for websites (except big players, like Facebook), it's less important - the most time of page rendering time is accessing and querying database.
In connecting database ASP.NET is a lot better - in asp.net we typically use LINQ which translates our object queries into stored procedures in SQL server database. Also connection to database is persistent, one for one website, there is no need for reconnecting.
PHP, in comparison, can't hold sql server connection between request, it connect, grab data from db and destroys, when reconnecting the database is often 20-30% of page rendering time.
Also whole web application config is reloaded in php on each request, where in asp.net it persist in memory. It can be easily seen in big, enterprise frameworks like symfony/symfony2, a lot of rendering time is symfony internal processess, where asp.net loads it's once and don't waste your server for useless work.
ASP.NET can holds object in cache in application memory - in php you have to write it to files, or use hack like memcache. using memcache is a lot of working with concurrency and hazard problems (storing cache in files also have it's own problems with concurrency - every request start new thread of apache server and many request can work on one time - you have to think about concurrency between those threads, it take a lot of development time and not always work because php don't have any mutex mechanisms in language, so you can't make critical section by any way).
now something about development speed:
ASP.NET have two main frameworks designed for it (Webforms and MVC), installed with environment, where in PHP you must get a open-source framework. There is no standard framework in php like in asp.NET.
ASP.NET language is so rich, standard library has solutions for very much common problems, where PHP standard library is ... naked... they can't keep one naming convention.
.NET has types, where PHP is dynamic, so it means no control about source code until you run it or write unit tests.
.NET has great IDE where PHP IDE's are average or average-good (PHPStorm is still a lot worse than VS+resharper or even without it)
PHP scaffolding in symfony is fired from command line when ASP.NET scaffolding is integrated into environment.
If you have slow computer like my (one core 2,2ghz), developing asp.net pages can be painfull because you have to recompile your project on any change of source code, where PHP code refresh immediately.
PHP language syntax is so unfinished, unsolid and naked compared to C# syntax.
Strong types in C# and many flexible language features can speed up your development and make your code less buggy.
In my (non-hardbenchmarked) experience Asp.Net can certainly compete (and in some areas surpass) PHP in terms of raw speed. But similar with a lot of other language-choice related questions the following statement is (in this case) valid (in my opinion):
There are slow, buggy sites in language x (be it PHP or Asp.Net)
There are great, fast sites in language x (be it PHP or Asp.Net)
What i'm trying to say: the (talents of the) developer will influence the overall speed more than a choice between two (roughly equivalent in some abstracted extent) technologies.
Really, an 'overall speed' comparison does not make a lot of sense as both can catch up to each other in some way or another unless you're in a very specific specialist niche (which you have not informed us about).
I have done performance test.
Program : Sum of 10000000 Numbers
Given output proves that php is slower than C#............
I'd say ASP.net
Things to consider:
ASP.net is pre-compiled
ASP.net is usually written in C#, which should execute faster than PHP
Granted, the differences are very minor. There's advantages to both, I think PHP is much easier to deploy and can run on any server not just IIS. I am quite fond of ASP.net MVC though.
I am a developer expert on both technologies (ASP.Net c# and PHP5).
After years and years of working and comparing them in real production environments these are my impressions:
First of all, cant compare them making a loop of adding values 1.000.000, this is not a real case.
Is not the same comparing them in my development environment than a real production env. Eg: In development ASP.Net does not use IIS by default, use a Inner Development server which has different optimizations. In dev, there is no concurrency.
So my opinion is the next:
Looping 1.000.000 times c# is going to be faster.(no-sense)
Serving a real page, that access DB, shows images, has forms etc....
ASP.Net is slower than PHP.
Weight of ASPX pages is x10 heavier than PHP, so this makes the final user to be waiting more time to get the page.
ASPX is slower to develop than PHP, this is important because at the end is money. We develop a 35% faster in PHP than ASP.Net, because of having to compile and restart every time u want to check smthg.
In big projects, ASP.Net in long term is better for avoiding errors and have a complex architechture.
Because of Windows Servers, IIS, .... at the end u need a powerfull server to hold the same amount of users on ASP than PHP. Eg: We serve with ASP.net arround 20.000 concurrent users and in PHP, the same server can get arround 30.000 users.
The only important thing is not if looping which one is faster. The thing is when website is real and is in production, how many users they can hold, how heavy is the page (heavier== more waiting time from users, more net charge of server, more disk charge of server, more memory charge of server).
Try the checking times with concurrency and u will see.
Hope it helps.
Without any optimizations, a .net compiled app would of course run "faster" than php. But you are correct that it's a stupid and irrelevant argument because it has no bearing on the real world beyond bragging rights.
Generally ASP.Net will perform better on a given hardware than PHP. ASP.Net MVC can do better still (can being the operative word here). Most of the platform is designed with enterprise development in mind. Testable code, separation of concerns etc. A lot of the bloat in ASP.Net comes from the object stack within the page (nested controls). Pre-compiling makes this better performant, but it can be a key issue. MVC tends to allow for less nesting, using the webforms based view engine (others are available).
Where the biggest slowdowns in web applications happen tends to be remote services, especially database persistence. PHP is programmed without the benefit of connection pooling, or in-memory session state. This can be overcome with memcached and other, more performant service layers (also available to .Net).
It really comes down to the specifics of a site/application. this site happens to run MVC on fairly modest hardware quite well. A similar site under PHP would likely fall under its own weight. Other things to consider. IIS vs. Apache vs LightHTTPD etc. Honestly the php vs asp.net is much more than raw performance differences. PHP doesnt lend itself well to large, complex applications nearly so much as asp.net mvc, it's that simple... This itself has more to do with VS+SCC than anything else.
I'd tend to agree with you (that ASP.NET MVC is faster), but why not make a friendly wager with your friend and share the results? Create a really simple DYNAMIC page, derived from a MySQL database, and load the page many times.
For example, create a table with 1,000,000 rows containing a sequential primary key, and then a random # in the second column. Each of your sites can accept the primary key in a GET, retrieve the random # based on the passed in key, and display the random # in some type of dynamically generated html.
I'd love to know the results ... and if you have a blog or similar, the rest of the world would too (this question gets asked ALL the time).
It would be even better if you could build this simple little app in regular ASP too. Heck, I'd even pay you for these results if the test was well designed. Seriously - just express your interest here and I'll send you my e-mail.
Need to note that question is .NET MVC vs PHP, not .NET (Web Forms) vs PHP.
I don't have the facts, but general feeling is PHP websites run faster than .NET Web form sites (and I do .NET only). .NET web forms despite being compiled vs interpreted PHP is generally slow because all the chunk of code that is autogenerated by the .NET engine to render the HTML for each < asp:control > you use on design mode. Getting a .NET web form to compete in speed with PHP is a complete odisea that starts with setting EnableViewState = false, and can end on using every html control with runat=server... crazy uh?
Now, MVC is a different story, I had made two websites using .NET MVC2 and feeling is good, you can feel the speed now! and code is as clean as any PHP website. So, now, MVC allows you write clean code as PHP does, and MVC is compiled against PHP interpreted, it can only lead to one thing, MVC faster than PHP... time will prove, when the general sense is "MVC websites runs faster than PHP" then we will be right about what I say here today.
see/you/!
C++... Right now the fight will be between PHP and ASP.NET. PHP will win on ease of use, ASP.NET will win on performance ( in a windows server ecosystem). A lot of the larger websites that started with php have graduated to C++.