As you already know there are compiled and interpreted languages. From a performance point of view which is better when visiting a website? Will a website that was developed with a compiled langauge will load faster and performs actions faster as will?

I want to reach to a point where I can unnderstand the steps required in both compiled/ interpreted site in order to bring them on stage! (in this case to the user browser).

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

13

There are other factors that are enormously more consequential than compiled vs interpreted.
–
whatsisnameMay 11 '11 at 23:37

Websites are composed of multiple languages and so this isn't an easy question to answer. Does JavaScript count as compiled or interpreted? What if one uses languages that combine some interpretation and some compilation? Just something to toss out there.
–
JB KingMay 12 '11 at 15:31

No, I don't know that there are compiled languages and interpreted languages. There are languages that are usually compiled to machine code. Most other languages are usually compiled to an intermediate representation and interpreted (or in some cases further compiled) from there. Only rarely will a language be purely interpreted.
–
David ThornleyMay 12 '11 at 16:28

4 Answers
4

If you have a good overall architecture, it is unusual for the language to make much of a difference in website performance. Usually most of the time goes to fetching data from however you've stored said data.

However when it does make a difference, compiled languages are usually faster. However this difference is not necessarily inherent in the nature of compiled languages. With JIT techniques, theoretically interpreted languages could be just as fast. See http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html for details, and see recent improvements in JavaScript to see this being put into practice.

With JIT techniques, theoretically JIT-compiled languages could be just as fast... provided you ignore the time required to do the compiling. With a traditionally compiled language, a bunch of work has been done in advance. With a JIT compiled language, by definition, it hasn't - though it may only happen once. There's also optimisation to consider - JIT-speed is an important design consideration, so some optimisations won't be included that would be done in traditional compilation. Though profile-based optimisations probably favour the JIT model. It seems a complex trade-off to me.
–
Steve314May 12 '11 at 0:56

@Steve314: It is a complex trade-off. JIT takes time at runtime, but has access to better profiling data than a traditional compiler and so can optimize better. Also compiled vs interpreted don't have simple dividing lines. Virtually no "interpreted languages" are truly interpreted any more. And what would you consider Java, which needs to be compiled, is run in interpreted byte code, and JITs down to native machine code while it is running?
–
btillyMay 12 '11 at 1:16

I should have said - I already gave the +1. Although I'm pedanting on the (mis)interpretation that "just as fast" means "equivalent performance", you're certainly right that this is usually a non-issue either way, and I guess you'd agree with me that any general assumption about which will be faster could easily be wrong for some specific application or for some particular platform anyway.
–
Steve314May 12 '11 at 1:34

Almost all non-really-high-performance websites are written using interpreted languages (PHP, C#/.Net, Java, Python, Ruby, and others) because they are much much easier to modify, update, setup and run than the most popular compiled languages.

Still you have to have very good reasons to use compiled code for websites as they are less easy to modify. An example an C++ framework that clearly states why it is done and when it should be used is CPPCMS. Here is the rationale, that explains clearly why you should try compiled languages in some specific cases. Main reasons : (high-)performance and use less resources than in alternatives.

+1 with reservations. "Dynamic" is not the opposite of "compiled". Python is both dynamically typed and compiled, though it's compiled into a kind of byte-code and executed by a virtual machine - similar to the statically-typed and compiled Java. On performance, compiled vs. interpreted isn't really a simple either/or thing these days, and the relevance of dynamic typing is that (irrespective of whether it's compiled or interpreted) the what-type-is-this evaluation is delayed to run-time. What and how much is delayed to run-time is relevant both to performance and ease of development.
–
Steve314May 12 '11 at 0:06

1

Of course client-side languages (particularly Javascript) are usually thought of as interpreted, even though they are normally compiled (on the client) in practice. There's a kind of I'm-deploying-the-source-not-a-binary thing. A virtual-machine binary can be deployed on the internet (as with Java), but native-compiled binaries obviously aren't portable. On the server, this may not be an issue, but using a non-portable server-side language may limit your options in the future.
–
Steve314May 12 '11 at 0:11

I have to replace "dynamic" by "interpreted", that's what I meant and wrote it wrong anyway. Thanks for the comments.
–
KlaimMay 12 '11 at 8:28

@Steve314: It's more orthogonal than that: Common Lisp is dynamically typed, and many implementations simply compile it to native code. The "interpreter" can be a JIT compiler.
–
David ThornleyMay 12 '11 at 16:30

There is no general answer to your questions. Without knowing the exact application, its exact load and its exact architecture it simply isn't possible to say "scenario X would be better solved using a compiled language and scenario Y would be better solved using an interpreted language".

There are factors that contribute a lot more (we're talking about orders of magnitude) to making a web application (more) performant than the choice of a language or a language type (compiled vs. interpreted). Even if you can clearly measure, that an application using a compiled language is faster than an interpreted language (or vice versa) the question still remains: Does it matter? Most of the time in typical web application is spent receiving and sending data via HTTP and waiting for results from the database.

That's a lot more time than anything you can optimize by choosing a specific language. So if a request in scenario A takes, let's say 200 ms and by choosing a different language you can reduce that time to 195 ms: Does is matter to the user? Does is matter to the hardware? Much more important: What do you give up for the increase in speed? Maybe it's faster but a lot harder to read, understand and extend?

So, no - in general it doesn't depend on what type of language you choose to implement your solution.

What happens in the user's browser is up to the user and the browser implementer. Compiling Javascript is getting increasingly popular, but you don't have any control over that.

The speed of your servers may be limited by quite a few things. Some likely things are connections with users and connections with databases. If you want to improve speed, find the bottleneck and fix it. If your CPU usage is 30% while your internet connections are swamped, improving the speed of your programs will do almost nothing. Similarly, if your back end processing is dominated by database operations, speeding the code up will do very little.

If you're doing a lot of computation per hit, then it is possible that application speed itself is important, and if you can do the computation in a language designed for it like C++ or Fortran you might speed things up enough to be worthwhile. Here I'm recommending doing the computation in a normally fast language, not the whole thing. A language like Python handling the requests and passing off the hard stuff to C++ modules will usually do very nicely.

Normally, before doing that, I'd like to do a stress test on the system to see if it actually matters. Run one server until it maxes out, and see where it's maxed out or nearly maxed out. Fix that if possible, and you may want to try it again. Don't worry about specific types of performance until you have good reason to believe it matters.