Is slower performance of programming languages, really, a bad thing? [closed]

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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.

Answer 8

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.

Answer 9

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)

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.