rate ++a,a++,a=a+1 and a+=1 in terms of execution efficiency in C.Assume gcc to be the compiler [duplicate]

Question

Possible Duplicate:
Is there a performance difference between i++ and ++i in C++?

In terms of usage of the following, please rate in terms of execution time in C. In some interviews i was asked which shall i use among these variations and why.

a++
++a
a=a+1
a+=1

Answer 1

Here is what g++ -S produces:

void irrelevant_low_level_worries()
{
    int a = 0;
//  movl    $0, -4(%ebp)

    a++;
//  incl    -4(%ebp)

    ++a;
//  incl    -4(%ebp)

    a = a + 1;
//  incl    -4(%ebp)

    a += 1;
//  incl    -4(%ebp)
}

So even without any optimizer switches, all four statements compile to the exact same machine code.

Answer 2

You can't rate the execution time in C, because it's not the C code that is executed. You have to profile the executable code compiled with a specific compiler running on a specific computer to get a rating.

Also, rating a single operation doesn't give you something that you can really use. Todays processors execute several instructions in parallel, so the efficiency of an operation relies very much on how well it can be paired with the instructions in the surrounding code.

So, if you really need to use the one that has the best performance, you have to profile the code. Otherwise (which is about 98% of the time) you should use the one that is most readable and best conveys what the code is doing.

Answer 3

The circumstances where these kinds of things actually matter is very rare and few in between. Most of the time, it doesn't matter at all. In fact I'm willing to bet that this is the case for you.

What is true for one language/compiler/architecture may not be true for others. And really, the fact is irrelevant in the bigger picture anyway. Knowing these things do not make you a better programmer.

You should study algorithms, data structures, asymptotic analysis, clean and readable coding style, programming paradigms, etc. Those skills are a lot more important in producing performant and manageable code than knowing these kinds of low-level details.

Do not optimize prematurely, but also, do not micro-optimize. Look for the big picture optimizations.