What makes a program inefficient?

Question

are there any main factors in which the programs efficiency depends?

Answer 1

The biggest factor is your program's data-structure and algorithm choice on a high level, as well as the overall architecture of your program.

You should focus on that before anything else.

There are multiple kinds of efficiency as well, such as memory efficiency vs. time efficiency. Different contexts require different focuses, but they are both most dependant on the above-mentioned topics.

Answer 2

The choice of data structures used often has significant impact.

Also, IO operations usually run orders of magnitude slower than anything else.

Answer 3

People tend to make poor guesses when answering this question. If you're writing a program with a well-known structure and answer, the efficiency problem has already been solved by others. If you are writing a new program, you might be surprised by the result of a profile.

Profiling and later optimization is, for front line programmers, almost always a better approach than trying to guess at the performance constraints at design time.

Answer 4

Probably unclear expectations is a big killer.

If you do not clearly know what you or your customers want it is difficult to properly architect a solution or select proper algorithms.

It is then impossible to make the proper trade-offs, e.g. space vs cpu, speed vs precision, run time vs implementation time, ...

Also in these circumstances stakeholders demand everything and basically constrain development into no-mans land.

First establish clarity of what is expected.

Answer 5

This is not a concrete answer (and I doubt there is one), but this sample from Cormen's book is really great as an illustration to the effectiveness and optimization problem.

Answer 6

I'm surprised that the implementation language hasn't been mentioned yet.

For example, a game made in Python will likely hog way more resources than that same game made in C.

Answer 7

In the real world of business programming, programmer errors are a big cause of a program taking way too long. I'm thinking of such things as failure to have or use indexes in the database, and having a time-consuming step within a loop so it needlessly executes over and over.

In client server or web development, you often have a choice about which computer will do particular computation. One may be much faster than the other.

Answer 8

A program's efficiency depends on the programmer's experience. As you get better and learn more stuff, your programs get faster and better too.

Answer 9

I wouldn't look at it that way. That's like asking "What makes an automobile efficient?"

I prefer to ask "What do we have to accomplish, and what's the bare minimum needed to accomplish it?"

For example, if I need to get from Boston to New York, there are a certain number of miles to be covered, and there is no way to avoid it. I can make the trip longer than that by dawdling about, going shopping, visiting friends and museums and interesting places along the way, all of which can certainly be justified, but it makes the trip longer, maybe a lot longer.

This is what happens in software. We dawdle about doing things because they seem like the things to do, rather than asking what is the bare minimum that absolutely has to be done.

For example, a recent question posed a situation where there was a very large file consisting of a series of records of different sizes, and some simple calculation needed to be done over the entire file. The question was asking if the records should be loaded into malloc-ed structs and wouldn't that seem to be slow? The bare minimum that has to be done is to read the file. The calculation should be tiny compared to reading the file. The program should be I/O bound. The issue of malloc shouldn't even be on the radar unless there is no way to avoid it.

Here's an example of where a program is speeded up by a large factor by finding out what it is doing that doesn't strictly need to be done. First we look and find out that it is spending nearly half of it's time doing what amounts to iterating iterators. Well, iterators are fine things, but in this case incrementing array indexes makes that portion of time basically go to zero. That done, we look again, and of the remaining time, we again find a healthy fraction of time going into general data structure manipulation, which can be done just as well by something simple. In this way, we collect the "low-hanging-fruit" until the program is considerably faster, and we know what it's doing, but to make it much faster will require a re-design. That's like switching from automobile to motorcycle. If we do that, then more stuff appears that we can get rid of, in stages. Each thing we remove makes the program faster by a healthy factor, and these factors compound into blazing overall speedups, much in the way a whip cracks, by transferring momentum into smaller and smaller masses until they break the sound barrier. (However, if we miss any one of them along the way, our improvement stops right there.)

If you get experience doing that, then you tend to solve problems in ways that are closer to optimal from the beginning.