Here's how I see it.

There's machine code and it's all that computers needs in order to run something. Computers don't care about programming languages. It doesn't matter to them whether the machine code comes from Perl, Python or PHP. Programming languages don't serve computers. They serve programmers.

Some programming languages run slower than others but that's not necessarily because there is something wrong with them. In many cases, it's because they do more things that programmers would otherwise have to do (i.e. memory management) and by doing these things, they are better in what they are supposed to do - serve programmers.

So, is slower performance, of programming languages, really, a bad thing?

closed as not constructive by Justin Cave, gnat, Martijn Pieters, Kilian Foth, thorsten müller Apr 2 '13 at 8:37

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 22
    slower in what way? compile time, runtime, write time, some other metric? – Matt Ellen Feb 22 '11 at 11:28
  • 1
    I would just point out that fast computers, and compilers that generate efficient machine language, are obviously good except that they allow programmers to be more lazy, by a lot. When products have performance problems, it is often because of assuming that certain things are "fast", like memory management and notifications. – Mike Dunlavey Feb 22 '11 at 13:49
  • 5
    @Mike: Alternately, programs run slow because of an attitude Jeff summed up nicely in his blog recently: "Algorithms are for people who don't know how to buy RAM". If the program runs on cubic time rather than O(N log n) time, computer power really doesn't matter for large problems. – David Thornley Feb 22 '11 at 14:44
  • 2
    @David: we can't get more than 512Gb of RAM in our server, so we have to write better algorithms now. – JBRWilkinson Feb 22 '11 at 18:58
  • 2
    Depends on where the bottlenecks are. If the program waits on I/O 99.9% of the time it doesn't matter if the program itself is 10 times slower than if written in handcrafted assembelr. – user1249 Oct 1 '11 at 13:00

14 Answers 14


I don't think it's automatically bad. Python is slower than C++, but when both are fast enough, Python may be the best choice for the problem at hand even if it's slower.

It's always a tradeoff. For small one-off tasks, it's much faster to write a Python script than a C++ app that does the same (the typical example for me would be some kind of batch text processing or walking a directory tree and doing something to the files), and I don't really care whether it takes 10 ms or 1000 ms, even though it's 100x slower, because it may take me half the time to write and test.

Of course, it would be nice if Python was as fast as C++, so in that sense I agree with your statement that "slow = bad". But then I rather have a powerful language that runs as fast as I want by not doing some things (say, array bounds checking on raw arrays) as long as it allows me to decide when to make that tradeoff (say, by using std::vector).

  • I didn't state that "slow = bad". Nevertheless, thanks for sharing your thoughts. – Emanuil Rusev Feb 22 '11 at 11:47
  • 9
    +1 'fast enough' Slow is bad when an implementation is 'too slow / not fast enough'. Any other time it doesn't matter. – Kirk Broadhurst Feb 22 '11 at 12:53
  • 4
    +1 'fast enough'. Depending on what you do, the programmer's time might be worth A LOT more than the potential savings in execution time. – Jonas Feb 22 '11 at 16:58
  • 3
    @Jonas: its almost never the case, it's just that you do see the programmer salary; you don't see the users hanging their heads in frustration as the app crawls along shouting "come on, how hard is that, you pile of crap software". If they published the TCO of slow software v fast software - you'd see your priorities being changed your sales dept immediately. – gbjbaanb Oct 1 '11 at 14:23
  • 1
    @mcmcc: I wasn't talking about languages there, but about the user experience. When you click on a button, something has to happen right away. When you launch a calculation, it's fine if it takes a while, as long as there's an useful progress indicator. – Jonas Apr 3 '12 at 16:42

Pretty simple - being slow is a bad thing

when the program requires a certain level of performance

because without that performance you aren't fulfilling requirements.

This could be anything from an business application that needs to process queries in an acceptable amount of time through to a game that needs to display a lot of information on screen at any point in time. If the program isn't fast enough, then it just doesn't work.

  • 2
    ..and often the requirements are unwritten in a kind of "more than X seconds to fetch a page makes the average website user move onto another site instead" way – JBRWilkinson Feb 22 '11 at 18:56
  • 1
    @JBRWilkinson yes, or if the system is too slow then new performance requirements will suddenly appear ;) – Kirk Broadhurst Feb 23 '11 at 0:20

Look at it this way: computers are stupid. They ploddingly follow instructions that any moron with a trig table could follow. They obstinately insist on doing what you said instead of what you meant. Not a shred of self-direction or intuition. It's horrible.

The ONE thing a computer has going for it is, it's fast. Really! A knucklehead with a filing cabinet could do the same job as a database. Some guy cranking a printing press could do what Apache does. Seriously! And they DID, for hundreds and hundreds of years, as a matter of fact. Why a computer is good for ANYTHING is its speed.

So a programming language that (compared to other languages) fails to exploit that is missing the ONLY advantage of using computers.

  • 13
    You're missing one important bit: computers are stupid, fast and pridictable, whereas erratum humanum est. And in many cases this predictability is a way much more important than a sheer speed. – SK-logic Feb 22 '11 at 13:54
  • 5
    Any programming language exploits computer speed. Python on one of the original OLPC computers does things a lot faster than I can by hand. Bear in mind that my current laptop (bought two years ago, and not top of the line then) is roughly a hundred thousand to a million times more powerful than my first home computer in most ways. – David Thornley Feb 22 '11 at 14:50
  • 4
    Not to mention that an computer consumes a lot of energy to use (particularly servers), and that there is a perceived worry with energy consumption (the green tech), and that usually a faster program does more with the same amount of energy as a slower program, so that counts (particularly on the servers, that consume a lot) – Coyote21 Feb 22 '11 at 14:54
  • 4
    @SK-logic Computer predictability is way overstated. As Joseph Weizenbaum pointed out very well, large system tend to get so complicated that they are in no way predictable and nobody is able to PREDICT the outcome of a certain execution. It becomes a matter of faith or hope. You can not formally prove that a program will always do what you intented (therefore it's not predictable). – Omar Kohl Feb 22 '11 at 16:08
  • 2
    Yet if speed (of execution) is the ultimate goal why don't we all write our programs in machine code? – Emanuil Rusev Feb 22 '11 at 16:31

A programming language can be very high level, "do a lot", still be very fast. OCaml is a higher-level language than PHP, but it is producing a code almost as fast as C. Javascript is as dynamic as PHP, but it can be executed really fast. So, it is mainly an issue with a language implementation, not a design. Dynamic languages are harder to implement efficiently, but not impossible.

  • Do you think languages that are considered slow (in terms of running), such as PHP, can be implemented to run faster? – Emanuil Rusev Feb 22 '11 at 11:49
  • 1
    Zend Optimizer anyone? – user281377 Feb 22 '11 at 11:56
  • Let me ask this another way - what in the implementation of PHP makes it slow? – Emanuil Rusev Feb 22 '11 at 11:57
  • 6
    Yes, it can be implemented better. It will require a lot of effort - an abstract interpretation to specialise dynamic types, for example, is quite a tricky thing and not well researched yet. A static language is much easier to translate into a highly efficient code. So, PHP is slow mainly because it is dynamic. And, well, originally it had a very poor and unprofessional implementation, as well as many other scripting languages. – SK-logic Feb 22 '11 at 12:19
  • HipHop compiler, started by Facebook, can translate PHP into C++ code, so it is really fast. – JBRWilkinson Feb 22 '11 at 18:55

Speed can be measured in terms of run-time, initial development time and maintenance time (time taken to turn over issues / bugs and produce new code and deploy it).

Scripting languages generally have slower run-time but faster maintenance time because you can often make a quick change and deploy without having to rebuild an entire system, and sometimes without even having to stop and restart.

Therefore a lot is a balance depending on the speed you require.

Context is important too. Loading your initial configuration taking 0.5 seconds instead of 0.1 seconds is no big deal, but at runtime, taking 0.5 seconds to perform a query instead of 0.1 seconds might be a big deal if it has to handle 100 queries, thus taking 50 seconds instead of 10.

  • 100ms is effectively instantaneous in user perception. 500ms is quite noticeable. If the user is performing queries, that's a noticeable difference in workflow. – David Thornley Feb 22 '11 at 20:58

Simple - customers love fast software. In fact the whole purpose of computers is to compute quickly.

  • 11
    wrong, actually. Customers love software that performs to requirements and within budget. They couldn't care less if a screen takes 19 milliseconds to build rather than 15, because they never notice (if it takes 15 seconds to build, that's something else). They also don't care whether you use a "fast language", they just want something that performs to specifications and within budget. – jwenting Feb 22 '11 at 13:43
  • 4
    19ms vs. 15 ms may not make a difference, but 500ms vs 300ms definitelly does and it may make a difference between a successful product and a failure. – Nemanja Trifunovic Feb 22 '11 at 14:10
  • 2
    +1 "Customers love software that performs to requirements and within budget." On the other hand, certain end users, who are not directly paying for the software, like employees of a large company, don't really care about development costs. Of course as a software vendor your most important task is to keep those people happy, who actually pay you. – Zsolt Török Feb 22 '11 at 17:10
  • @Zsolt: That really depends on the kind of software you are developing. I usually work on products where end-users either pay for the products directly or influence purchasing decisions - they don't give us specifications and don't care about our budget. Maybe I should have used term "users", rather than "customers". – Nemanja Trifunovic Feb 22 '11 at 17:38
  • 4
    Speaking as a user (rather than as a developer), I can say general responsiveness (note: different than speed) is a major factor in my decision to choose one program over another. This is one reason I use few Java applications for example; the startup time on the JVM alone results in apps that start out with -5000 points in this area ;). Seriously though, responsiveness can (often does) make the difference between your product UI being clunky or being effective, and sometimes that can be difficult to achieve if the language you're using induces stutters or long disk i/o waits. – Billy ONeal Feb 22 '11 at 18:04

Slow is relative. If I have a requirement to read a port 10 times per second, a language that cannot create a binary that can do that is too slow. If otoh I'm writing a web application where the request/response sequence between server and browser/client is measured in seconds and the user is likely to spend minutes on a screen before clicking a button, a programming language that can handle the request processing in 1 second is probably fast enough (most of course are much quicker).

Of course the programming language might be a factor in determining the speed of execution, but that won't be the language itself but the compilers and/or runtimes that come with it. This is clear seeing the development of Java, where the performance of JVMs (even on identical hardware environments) has over the years increased radically. And of course it's always possible to write terribly slow code in whatever environment you choose. As such claims like "C++ is ten times faster than Java" are automatically bogus unless qualified and quantified as to exactly which conditions were tested and how. It's equally possible to create a test where Java is faster than C++, it all depends on what you're using as test code and how you execute it.


Because programming languages don't exist to serve programmers, they exist to create programs to serve users.

If you just need a simple little personal tool to do something one time, it can be as slow as you want. But once you start to deploy to users, they care about speed and scaling, especially if they're going to use it repeatedly. (For example, an installer can be slow; the program it installs had better not be.) And it's not just the language; it's the program overall. If your program is slow, users won't like it. And if you have competition, users not liking your program is a very bad thing. So a language that contributes to users not liking your program (by making it slow) is bad.

I'm part of a team that writes control software for broadcast media. There's a good chance your favorite TV or radio station is running on it if you're in the USA. Performance is one of the things we hear about most often from clients. It was originally written for little single-station operations, but now we're signing major broadcast and cable networks with hundreds of channels, and scale starts to become an issue. If we can't make things run fast for them, they'll take their multimillion-dollar contracts to people who can, and we end up out of a job. That's why we use a fast, compiled language and optimize the heck out of our databases.


Because faster is better. Time is money. If you write server software and you use a slower programming language, you buy more servers. If you write a shrinkwrapped software, you lose customers to rivals who are faster.

For any sort of lasting software that are used by people, we usually want it as fast as possible. At Assembly level, the time-to-market increases too much that it's not profitable. It's all trade-offs. From a business perspective, it might be more profitable to let the poor programmers debug memory errors in C++, doing it for several more months, if it means the product is faster than your rivals.

So speed is actually important in many software. Slow languages are considered "bad" nowadays because they are really too slow (Python can easily be 50x - 100x slower, and that's too much)


Programming languages exist to serve programmers.

I don't know how you came to this conclusion. I would say: software engineers use programming languages for their needs.

Some programming languages are slower then other but that's not because there is something wrong with them.

This is also a flakey statement. Define what you mean by using the word 'slower' here. Slower could mean:

  1. Final programs, that achieve the same thing, run 'slower' in one language in comparison to another.
  2. The time taken to create the final program may be longer (hence, some would describe it as 'slower').

These two issues that come to mind are also intertwined where there's some kind of trade-off between time spent on development and performance.

  • 3
    You are right saying that "software engineers use programming languages for their needs". This only supports the statement that "programming languages exist to serve programmers". – Emanuil Rusev Feb 22 '11 at 11:43
  • 1
    I would say: software engineers use programming languages for solving problems (which are typically not their own, but their clients'). – Péter Török Feb 22 '11 at 11:43
  • @Emanuil: I would not say "a hammer serves a handyman/human", but that a hammer is used to complete a task (e.g. hammer a nail, hit someone you don't like, etc.). @Péter: I wonder how many people just write '@Peter'. But if you can coin the term 'problem' for everything, I think our statements are effectively synonymous. – Jonathan Khoo Feb 22 '11 at 11:51

Like any software, being slow can be a sign of underlying problems/bad design. Design is a bit of a zeitgeist admittedly, but this doesn't detract from that fact the design principles it is now based on are out of date and considered 'bad'.

Take Classic ASP and ASP.net for example.


Someone commented that "Customers love software that performs to requirements and within budget". Well, this is true - but it has quite a bearing on slow software, and that, almost by definition means slower programming languages (and frameworks) and algorithms, and configuration. A slow programming language is possibly the most important part of all the above simply because its a foundation from which you will find it most difficult to change. If you use an Oracle DB and need more perf, you can optimise the tables/index/etc. Easy. If you have a poor algorithm in your code, you can write different code. If your framework is slow, you can replace it - that's not so easy but it is do-able without re-writing everything. If your language is too slow, you have to practically start again.

See Facebook for the hassle they went into to make PHP work fast enough when they needed to scale.

For the rest of us, 'non functional performance requirements' are often written into specifications, especially for scalable web apps. Fail to fulfill the 'page must be displayed to the user within 2 seconds of request" and you lose the contract (or pay penalties). So, yes customers love software that performs to reqs - and those reqs will say it has to be fast. (you may not care how long the users spend staring at the hourglass, but the customer sure does - its a huge cost).

For an example, at a large call centre I was told that they'd determined that for every second you could save on the call-taking process, 1 calltaker could be 'downsized'. That's real money suddenly, and a huge incentive for the bosses to get faster, efficient and more usable, software.

There's a lot of time spent worrying about programmers churning out code as fast as possible (and then unit testing and refactoring all the time, lol). I have found that this isn't as much of a factor as people think it is - if you're an expert in your language, you can code it much faster than if you're inexperienced. So a expert C++ dev can write code faster and more accurately than a novice PHP dev. So I think becoming an expert is more important than choosing an 'easy' language and this is why I dislike the cult of the 'rewrite in the cool, new stuff' that seems to be everywhere today.


I'll point out that most the performance problems exist because the programmer did a bad job not because the language was too slow. Really, there are many more pertinent things to worry about in performance than the language you choose. That would be approximately number 1,203,407th on my list.


So, is slower performance, of programming languages, really, a bad thing?

Everything else being equal, going faster is a good thing. After all, nobody really wants to wait longer for some results, and once that result is done it can free up resources for other things.

But not everything else is equal. For starters, it's also important to produce the right result, or at least right-enough. (If completely wrong results are allowed, you can produce those very quickly indeed and they will be of exactly zero value to anyone.) If a change to a somewhat slower language makes it more likely that the right result will be produced, that's typically a great trade-off. Higher-level languages have an advantage over lower-level ones here, as their richer set of models usually makes it easier to express a complex problem without overwhelmingly much explicit detail.

It's also usually important to manage the cost of producing the software in the first place, of adding new features as desired, and of keeping it working as the underlying systems change. Higher-level languages usually allow for faster programming turnaround, and there's a lot of value in keeping the costs of programming within budget. Indeed, keeping costs there down allows more different things to be achieved overall, which is generally a good thing.

The final key point to note is that it is not necessary to use just one language, and that many software systems have a majority of their components being not performance critical. Using a low-level language to produce high-performance components for the critical bits is sensible, while leaving the less critical parts to a high-level language (so as to minimize the cost of producing them) is eminently sensible. What's more, the features that make a good low-level language (the ability to control precisely what the machine does) are not the features that make a good high-level language (the ability to infer the details from much smaller descriptions): they are diametrically opposed, so being able to couple them together and use them for their strengths and avoid their weaknesses, that's a great thing indeed.

Which components should get the high-performance treatment? The optimization? Measure them. Profile them. Find the truth rather than guessing. Focus your effort where it does most good.

Not the answer you're looking for? Browse other questions tagged or ask your own question.