Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Which is faster, python webpages or php webpages?
Does anyone know how the speed of pylons(or any of the other frameworks) compares to a similar website made with php?
I know that serving a python base webpage via cgi is slower than php because of its long start up every time.
I enjoy using pylons and I would still use it if it was slower than php. But if pylons was faster than php, I could maybe, hopefully, eventually convince my employer to allow me to convert the site over to pylons.
It sounds like you don't want to compare the two languages, but that you want to compare two web systems.
This is tricky, because there are many variables involved.
For example, Python web applications can take advantage of mod_wsgi to talk to web servers, which is faster than any of the typical ways that PHP talks to web servers (even mod_php ends up being slower if you're using Apache, because Apache can only use the Prefork MPM with mod_php rather than multi-threaded MPM like Worker).
There is also the issue of code compilation. As you know, Python is compiled just-in-time to byte code (.pyc files) when a file is run each time the file changes. Therefore, after the first run of a Python file, the compilation step is skipped and the Python interpreter simply fetches the precompiled .pyc file. Because of this, one could argue that Python has a native advantage over PHP. However, optimizers and caching systems can be installed for PHP websites (my favorite is eAccelerator) to much the same effect.
In general, enough tools exist such that one can pretty much do everything that the other can do. Of course, as others have mentioned, there's more than just speed involved in the business case to switch languages. We have an app written in oCaml at my current employer, which turned out to be a mistake because the original author left the company and nobody else wants to touch it. Similarly, the PHP-web community is much larger than the Python-web community; Website hosting services are more likely to offer PHP support than Python support; etc.
But back to speed. You must recognize that the question of speed here involves many moving parts. Fortunately, many of these parts can be independently optimized, affording you various avenues to seek performance gains.
There's no point in attempting to convince your employer to port from PHP to Python, especially not for an existing system, which is what I think you implied in your question.
The reason for this is that you already have a (presumably) working system, with an existing investment of time and effort (and experience). To discard this in favour of a trivial performance gain (not that I'm claiming there would be one) would be foolish, and no manager worth his salt ought to endorse it.
It may also create a problem with maintainability, depending on who else has to work with the system, and their experience with Python.
I would assume that PHP (>5.5) is faster and more reliable for complex web applications because it is optimized for website scripting.
Many of the benchmarks you will find at the net are only made to prove that the favoured language is better. But you can not compare 2 languages with a mathematical task running X-times. For a real benchmark you need two comparable frameworks with hundreds of classes/files an a web application running 100 clients at once.
PHP and Python are similiar enough to not warrent any kind of switching.
Any performance improvement you might get from switching from one language to another would be vastly outgunned by simply not spending the money on converting the code (you don't code for free right?) and just buy more hardware.
It's about the same. The difference shouldn't be large enough to be the reason to pick one or the other. Don't try to compare them by writing your own tiny benchmarks ("hello world") because you will probably not have results that are representative of a real web site generating a more complex page.
If it ain't broke don't fix it.
Just write a quick test, but bear in mind that each language will be faster with certain functions then the other.
You need to be able to make a business case for switching, not just that "it's faster". If a site built on technology B costs 20% more in developer time for maintenance over a set period (say, 3 years), it would likely be cheaper to add another webserver to the system running technology A to bridge the performance gap.
Just saying "we should switch to technology B because technology B is faster!" doesn't really work.
Since Python is far less ubiquitous than PHP, I wouldn't be surprised if hosting, developer, and other maintenance costs for it (long term) would have it fit this scenario.
an IS organization would not ponder this unless availability was becoming an issue.
if so the case, look into replication, load balancing and lots of ram.
The only right answer is "It depends". There's a lot of variables that can affect the performance, and you can optimize many things in either situation.
I had to come back to web development at my new job, and, if not Pylons/Python, maybe I would have chosen to live in jungle instead :) In my subjective opinion, PHP is for kindergarten, I did it in my 3rd year of uni and, I believe, many self-respecting (or over-estimating) software engineers will not want to be bothered with PHP code.
Why my employers agreed? We (the team) just switched to Python, and they did not have much to say. The website still is and will be PHP, but we are developing other applications, including web, in Python. Advantages of Pylons? You can integrate your python libraries into the web app, and that is, imho, a huge advantage.
As for performance, we are still having troubles.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm planning on moving to Python and I have a couple of additional questions along with the title:
did you have more fun with python?
are you as productive as when you're using PHP?
what made you change to python?
Would you do a project again in PHP? If so, why?
Your answers would really be useful for us PHP devs wanting something more I guess :)
Thanks in advance!
I was a PHP dev for about 5 years before switching to Python almost exclusively a year ago. The experience has been a mostly positive one; I'll answer your questions but also list a few gotchas I ran into.
Definitely. I continually find surprisingly powerful features/expressions in Python that do a great deal in a small amount of code (yet still being more readable than Perl).
Far more productive. It might just be my style, but Python's functional programming tools, generator expressions, list comprehensions, etc. allow me to accomplish tasks correctly with less code and less time invested than PHP.
I had an analytics project that needed a powerful stats package, so I went with Python+numpy. Then I found Turbogears and loved the syntax. Eventually I discovered coroutines and cooperative multitasking, and there's no going back. I use bottle, gevent, and gunicorn to crank out lean, fast, scalable web apps in record time.
Not if I could help it. PHP's verbose "everything is a long-named function call" syntax is just hard on my eyes at this point. I find it tedious to optimize as well (every page load reinterprets the source code in a default configuration).
Here are a few of the gotchas to be aware of:
For cheap, low-traffic sites, it's much harder to find a web host with a good python environment.
Apache isn't really a typical setup for Python in my experience. Python webapps are usually daemons that are exposed to the public with a reverse proxy webserver in front (nginx is very common). A number of corporate environments balk at new-fangled technology like nginx. It also takes some adjustment to think about your webapps as daemons, and it can take some effort at first to get your daemonizing correct and consistent.
If you use mysql, you will have some pain switching for a while. There just isn't a Python mysql library that is highly compatible with PHP-style mysql queries. For example, most of them don't use the simple "?" syntax for parameterized queries, so you can't just paste your queries over (you have to use printf-style "%s", etc.). Also, just the fact that you actually have to choose and install a mysql library is an extra step over PHP. This no longer bothers me, since I don't use mysql anymore anyway.
This is a broad topic with much, much more to say, but I hope this was helpful.
I'll try my best to answer your questions as best I can:
Did you have more fun with python?
I really enjoy how minimalist python is, having modules with non-redundant naming conventions is really nice. I found this to be especially convenient when reading/debugging other peoples code.
I also love all of the python tricks to do some very elegant things in a single line of code such as list comprehensions and the itertools library.
I tend to develop my applications using mod_wsgi and it took some time to wrap my head around writing thread-safe web applications, but it was really worth it.
I also find unicode to be much less frustrating with python especially with python 3k.
are you as productive as when you're using PHP?
For simple websites python can be less fun to setup and use. One nice feature of PHP that I miss with python is mixing PHP and HTML in the same file. Python has a lot of nice template languages that make this easy as well, but they have to be installed.
what made you change to python?
I became frustrated with a lot of the little nuances of PHP such as strange integer and string conversions and so forth. I also started to feel that PHP was getting very bloated with a lot of methods with inconsistent naming schemes. I was referring to the PHP documentation quite frequently despite having a large portion of the php library memorized.
Would you do a project again in PHP? If so, why?
I would develop a PHP project again, it has a lot of nice features and a great community. Plus I have a lot of experience with PHP. I'd prefer to use python, but if the client wants PHP I'm not going to force something they don't want.
Well, I started with PHP, and have delved into Python recently. I wouldn't say that I've "moved to", but I do use both (still PHP more, but a fair bit of Python as well).
I wouldn't say that I have more "fun" with Python. There are a lot of really cool and easy things that I really wish I could take to PHP. So I guess it could be considered "fun". But I still enjoy PHP, so...
I'm more productive with PHP. I know PHP inside and out. I know most of the little nuances involved in writing effective PHP code. I don't know Python that well (I've maybe written 5k lines of Python)... I know enough to do what I need to, but not nearly as in-depth as PHP.
I wanted to try something new. I never liked Python, but then one day I decided to learn the basics, and that changed my views on it. Now I really like some parts (and can see how it influences what PHP I write)...
I am still doing PHP projects. It's my best language. And IMHO it's better than Python at some web tasks (like high traffic sites). PHP has a built in multi-threaded FastCGI listener. Python you need to find one (there are a bunch out there). But in my benchmarks, Python was never able to get anywhere near as as fast as PHP with FastCGI (The best Py performed it was 25% slower than PHP. The worst was several hundered times, depending on the FCGI library). But that's based on my experience (which admittedly isn't much). I know PHP, so I feel more comfortable committing a large site to it than I would PY...
I run a self-developed private social site for 100+ users. Python was absolutely fantastic for making and running this.
did you have more fun with python?
Most definitely.
are you as productive as when you're using PHP?
Mostly yes. Python coding style, at least for me is so much quicker and easier. But python does sometimes lack in included libraries and documentation over PHP. (But PHP seems second to none in that reguard). Also requires a tad more to get running under apache.
what made you change to python?
Easier to manage code, and quicker development (A good IDE helps there, I use WingIDE for python), as well as improving my python skills for when I switch to non-web based projects.
Would you do a project again in PHP? If so, why?
Perhaps if I were working on a large scale professional project. PHP is so ubiquitous on the web A company would have a much easier time finding a replacement PHP programmer.
Last year I switched job to get away from PHP and work in Python. I'm very much satisfied with the decision I made :)
To answer the individual questions:
did you have more fun with python?
Yes!
are you as productive as when you're using PHP?
More productive I'd say. But the overall increased experience in programming also had something to with that.
what made you change to python?
You are not expected to be a jack of all trades in non-PHP jobs. (Photoshop/Web Design/Flash is required for many PHP jobs, and I hate Flash). And I liked Python/Django a lot.
4. Would you do a project again in PHP? If so, why?
If it's small stuff that's better done without any framework, then yes.
I've never really worked with PHP (nothing major) and come from the .NET world. The project I am currently on requires a lot of Python work and I must say I love it. Very easy and "cool" language, ie. FUN!
.NET will always be my wife but Python is my mistress ;)
yes
yes
curiosity, search for better languages, etc. (actually, I learned them somewhat in parallel many years ago)
yes, if a project requires it explicitly
disclaimer: I never really moved from php.
did you have more fun with python?
Yes. Lot more.
are you as productive as when you're using PHP?
No. I think more.
what made you change to python?
Django.
Would you do a project again in PHP? If so, why?
Only if it is required.
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.
The news in the PHP world today is Facebook's HipHop, which:
HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP's runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations.
My question is, what type of web applications is this actually useful for?
Seems like typical database-bound web apps may not be greatly served by this, but rarer CPU-bound apps would.
Web applications that do a lot of processing and/or use a lot of memory. Apparently this HipHop will reduce CPU usage by around 50% and also reduce memory usage (I didn't see how much the memory usage would be reduced by mentioned anywhere). This means that you should be able to serve the same number of requests with fewer servers.
An added benefit may be that there will be some basic type checking to ensure that the code is consistent before it is compiled. This should help to locate the type of bugs that PHP currently tends to ignore as a result of its weak type system.
The downside appears to be that it might not support some of PHP's more dynamic features such as eval (though arguably that's a positive too).
Well it "transforms" PHP into C++ to help performance of a largely scalable website.
So, HipHop is for when you have a website that you started at Harvard that you quickly grow into a billion dollar company and that people are making a movie about starring Justin Timberlake. When you have such a website and want to save CPU cycles, but don't want to rewrite your codebase, you use HipHop.
If you are just starting out, unless you are trapped on a desert island with only PHP programmers that refuse to learn a more scalable language, you don't use HipHop.
Running machine code over interpreted code is faster. This is useful in one sense, but also reduces the amount of machines you require, as each processor has less work to do.
This is good for a company like Facebook, in that they can cut the amount of machines they need.
In terms of why it's useful for them, they probably run a lot of sorting and indexing, on the large amounts of data they have.
This article:
http://terrychay.com/article/hiphop-for-faster-php.shtml
answers this question perfectly with its series of "if" statements.
You can think of it as some sort of compiler that takes in a bunch of .php files, and generate a bunch of c++ files for which you can then compile using g++ (Not sure if other compilers are supported). The resulting exe is your web application with a web server included. That means you could run the exe and you are good to go. The web server is based on libevent and supposedly pretty efficient.
Hip Hop is essentially pointless to everyone except Facebook and other gigantic PHP-based sites. I'm sure many people will jump on the bandwagon due to "it's fast" but how many PHP based apps use whole server farms?
Just because you are working on a social network site, doesn't mean you should consider using HH.
I build database-driven web sites. Previously I have used Perl or PHP with MySQL.
Now I am starting a big new project, and I want to do it in the way that will result in the most responsive possible site.
I have seen several pages here where questions about how to optimize PHP are criticized with various versions of "it's not worth going to great lengths to optimize PHP since it's an interpreted language and it won't make that much difference".
I have also heard various discussions (especiallon on the SO podcast) about the benefits of compiled vs. interpreted languages, and it seems as though it would be in my interests to use a compiled language to serve up the site instead of an interpreted language.
Is this even possible in a web context? If so, what would be a reasonable language choice?
In addition to speed one benefit I forsee is the possiblity of finding bugs at compile time instead of having to debug the web site. Is this reasonable to expect?
What you can do is what multiple heavy-traffic websites do (like Facebook or Twitter), aka write your "CPU consuming" algorythm in a C-plugin.
For example, you could write a PHP extension if you plan to use PHP, or a Ruby extension if you plan to use Ruby / Ruby on Rails, etc.
That way, you can keep your streamline code simple and easy to maintain (it might be way harder to handle request from C rather than from PHP), while having a strong and solid background core (because it's compiled, and the compiler tells you what the issues are at compile time)
If you were going to build a new language... and you came up with all the semantics and it was complete, and you had some magic box that had a switch between making the language compiled vs. interpreted, the compiled version would be faster than the interpreted version.
Why? Because compiling brings your semantics down to a lower level on the machine which means it can executed much faster, whereas interpreting means the semantics of your language will translated by some thing (i.e. the interpreter) when the user actually uses your site.
Having said that... that doesn't necessarily mean that your site is going to 100% run faster on a compiled language vs an interpreted language. There are interpreters out there that are very fast nowadays for various languages (i.e. PHP), and there are even optimizers for interpreted languages that make them faster even still.
There are many other things that go into the performance of your site that are agnostic of the language you choose. Hardware setup, Database setup, Network topology, etc. These things can have a bigger impact on you. I would suggest measuring to be sure.
For me, finding bugs at compile time is a huge time saver, so I tend to prefer compiled languages which are strongly typed. It lets me get my work done faster, but that doesn't make it objectively the best option. Some people have no issue writing weakly typed code, and running test suites on them to verify their functionality, which I would think would work just as well.
IMHO it is quite a non-sense to write a complex web app using a compiled language, as it gives not benefits against a number of manageability problems.
There a lot of ways to rise up performances and scalability in a scripted language, both at language level and at system level, being the minor performances gain eventually available with a compiled language totally influential.
On the other side I find very useful to be possible to follow an agile development and bug hunting schema, simply changing your code and seeing the results.
Perl isn't an interpreted language: it is compiled to bytecode, so you pay the price of interpretation only when the perl executable is started. So when using it with Apache, don't use CGI but mod_perl.
Whatever you do, development time is probably going to widely exceed response time if you pick a language that isn't suitable to web programming or doesn't have good libraries to support what you need to do. E.g. I'd never pick C or C++. You don't want a web app that is blisteringly fast but buggy and 6 months late.
Tomcat is a common way to use compiled languages to deploy webpages, but before you go too far, seriously consider what your speed bottlenecks will be. There are a few main sources of slowdown in web applications:
Network latencies
Static media, especially images
Database queries
Server-side processing code
Client-side processing code
1 and 5 don't really have much to do with this question.
2 will be relevant if you have many images that vary from page to page. If that's the case, client browsers won't do such a good job caching, and each page-load will take some time. In this case, it is very likely that your server-side language won't be noticed, because the overhead from static media will dominate.
3 is likely to be a bigger factor than 4 for a lot of applications. If you have very little data, but you do a whole lot of processing, then 4 may dominate, but otherwise, 3 will dominate even if you're using an interpreted language.
People can ask "Why optimize php?" because the 2 and 3 are often more important anyway. Often, a good database caching framework is going to be a better (and easier) optimization.
There are lots of parts that goes into a web application. The time taken by the application layer doesn't need to be big. For a typical application, the biggest hogs would be in the webserver and in the database. Replacing PHP with a binary cgi isn't going to change this.
Furthermore, while the interpreted parts of PHP may be somewhat slow, that is only a small part of what goes on in the execution of a PHP script. All the functions that are provided as part of the language are implemented in native code. For example, when you call a function like preg_match, it will call out a native code library and let it do its work. This means that there is less actual interpretation going on than you might think.
There may be some cases where using a different language than PHP might be worthwhile, but those are special cases. In general, there is nothing to gain here.
The latency of the network is by far the greatest determining factor in this argument. In fact, network latency is so much of a factor that it renders language considerations rather unimportant from a performance issue. So...go with what you know. Use the language that you are most comfortable and most productive with and other considerations can be worked out as you go along. Now, that said, it's always fun to try new stuff and learning new things can become an obsession, so if the project is a personal one that allows you the opportunity to experiment, well, by all means.....
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++.