There are a number of programming languages out there, each with their own quirks and features. Due to different design choices and use cases, some are faster or slower than others. Of course, this speed (or the lack of it) usually comes at a price. Put simply, it’s these differences that cause these performance changes.
What Is a Programming Language?
No matter how programming languages look, they’re still doing the same thing: getting your computer to do something. All lines of code are eventually translated to a series of obscure numbers (also known as machine code). It could be said that all programming languages past machine code (including assembly, which maps numbers to readable words) are designed to make creating software easier.
These languages can be classified by looking at the level of abstraction they do for programmers. Basically, that’s how much is taken care of by the language itself, things that on a lower level would be handled manually. This tends to make higher-level languages much easier to program in, because there’s a little less to learn and remember about.
An example of this is memory management. For some languages with less abstraction, a programmer has to manually say how much RAM they need for the task on hand, and then release it once it’s done. If they don’t do this, or if something happens that they don’t account for, this memory usage might grow and grow. Higher-level languages such as Java do this automatically.
The Cost of Automation
That being said, there are certainly some downsides to using higher level languages. Namely, speed. Sometimes, the more that’s taken out of a programmer’s control, the less efficient a program might become.
For example, languages with automatic memory management (usually called garbage collection) can be slower than ones which do not implement this. This is because the program needs time to go through itself and clear out memory at specific intervals.
Compiling: Your Mileage May Vary
Generally, programs written in languages such as C and C++ are said to be faster than most. Most operating systems are written using them, along with some even lower level assembly code. One of the main factors of this comes from them being compiled (as compared to being interpreted).
What this means is that before being run, the source of the program is first translated down into a lower level: machine code. The resulting products are called binaries (e.g. DLL files), which are linked together with the relevant files to make them work, creating what’s called an executable.
However, one drawback of this is the time it takes to actually compile such programs. Large ones such as Mozilla Firefox can take up a good half an hour or so. Fortunately, most software these days do this process beforehand, making it easier to just install and use.
Since the end result is written in a language that a computer can directly understand, it tends to be quite fast. Compare this to interpreted languages, which go through another step. Having said that, not all compiled languages are the same.
To translate any sort of code into something a computer can understand (machine code), it needs to be run through a special program called a compiler. One language can have multiple compilers for it. For example both GCC (GNU Compiler Collection) and Clang can be used to compile programs written in C.
Since it’s the compiler’s job to translate a program into machine code, how well it does this can impact its speed somewhat. The same source can have slightly different results, depending on how the compiler is configured, for example.
This can also mean that different compiled languages can perform faster or slower than others. Generally, C and C++ are said to be very fast, since the compilers for them have gone through years of development and improvements. Other languages don’t always have that maturity.
Interpreted Language: One More Step
As said before, interpreted languages are not compiled beforehand. Instead, they are translated whilst being run, usually by a separate program known as an interpreter. For example, Java programs are run through something called the JVM (Java Virtual Machine).
Because these languages don’t need prior compilation, programs written in them are generally much easier to make and test. As a result however, the software itself can be significantly slower. Interpreters execute the source of a program line by line, which incurs a speed penalty. Along with this, the interpreter itself needs a little time to start up.
Bytecode: A Slight Compromise
Due to their somewhat slower nature, many interpreted languages actually use some form of compiling to speed up their performance. Before running, these programs are translated down to bytecode, a type of language easy for interpreters to work with. For example, both Java and Python do this before running, creating CLASS and PYC files, respectively.
Basically, it’s a bit of a compromise between ease of development and speed. It’s faster than just interpreted code, and easier to set up than its fully compiled counterparts. Bytecode also has the added benefit of being more portable compared to programs compiled to machine code. If the interpreter exists for the CPU architecture, it will run.
In some languages, there’s also something called JIT (just-in-time) compilation. Basically, it takes bytecode and compiles bits of it down to machine code. Like the name suggests, this happens while the program is running. It’s meant to speed up execution, at the cost of a slower first start since parts of it need time to compile.
Don’t Sweat It
All this being said, these differences are not really a problem for most people, especially with computers becoming faster and faster every year. While some programming languages are certainly faster than others, what really matters is it gets something done.
Sure, if you’re very experienced with programming, it’s fine trying to eke out performance from your code. But if you’re just starting out, it’s much better to worry about learning the motions in the first place. It doesn’t matter how fast or slow a language is considered if nothing is written in the first place after all.
There’s also the matter of using the right tool for the job. Assembly language for example is very good for writing operating systems, because it’s so low level. But it’s overkill for regular desktop applications. There are also languages designed for the web, and so on.
What factors do you consider when learning a programming language?