Interpreted vs. Compiled Languages for Web Sites (PHP, ASP, Perl, Python, etc.)

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:

1. Network latencies
2. Static media, especially images
3. Database queries
4. Server-side processing code
5. 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.....