Preincrement Faster Than Postincrement in C++ - True? If Yes, Why Is It

Preincrement faster than postincrement in C++ - true? If yes, why is it?

Post-increment usually involves keeping a copy of the previous value around and adds a little extra code. Pre-increment simply does it's job and gets out of the way. I typically pre-increment unless the semantics would change and post-increment is actually necessary.

Efficiency of postincrement v.s. preincrement in C++

pre-increment introduces a data dependency into your code -- the CPU must wait for the increment operation to be completed before its value can be used in the expression."

Is this true?

It is mostly true - although perhaps overly strict. Pre increment doesn't necessarily introduce a data dependency - but it can.

A trivial example for exposition:

a = b++ * 2;

Here, the increment can be executed in parallel with the multiplication. The operands of both the increment and the multiplication are immediately available and do not depend on the result of either operation.

Another example:

a = ++b * 2;

Here, the multiplication must be executed after the increment, because one of the operands of the multiplication depends on the result of the increment.

Of course, these statements do slightly different things, so the compiler might not always be able to transform the program from one form to the other while keeping the semantics the same - which is why using the post-increment might make a slight difference in performance.

A practical example, using a loop:

for(int i= 0; arr[i++];)
count++;

for(int i=-1; arr[++i];) // more typically: (int i=0; arr[i]; ++i;)
count++;

One might think that the latter is necessarily faster if they reason that "post-increment makes a copy" - which would have been very true in the case of non-fundamental types. However, due to the data dependency (and because int is a fundamental type with no overload function for increment operators), the former can theoretically be more efficient. Whether it actually is depends on the CPU architecture, and the ability of the optimizer.

For what it's worth - in a trivial program, on x86 arch, using g++ compiler with optimization enabled, the above loops had identical assembly output, so they are perfectly equivalent in that case.


Rules of thumb:

If the counter is a fundamental type and the result of increment is not used, then it makes no difference whether you use post/pre-increment.

If the counter is not a fundamental type and the result of the increment is not used and optimizations are disabled, then pre-increment may be more efficient. With optimizations enabled, there is usually no difference.

If the counter is a fundamental type and the result of increment is used, then post-increment can theoretically be marginally more efficient - in some CPU architecture - in some context - using some compiler.

If the counter is not a fundamental type and the result of the increment is used, then pre-increment is typically faster than post-increment. Also, see R Sahu's answer regarding this case.

Which one is faster post increment or pre-increment?

There are few answers out there:

http://www.geekinterview.com/question_details/14424

http://www.digitalpeer.com/id/where

but this question is a duplicate

Preincrement faster than postincrement in C++ - true? If yes, why is it?

---andrew

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

[Executive Summary: Use ++i if you don't have a specific reason to use i++.]

For C++, the answer is a bit more complicated.

If i is a simple type (not an instance of a C++ class), then the answer given for C ("No there is no performance difference") holds, since the compiler is generating the code.

However, if i is an instance of a C++ class, then i++ and ++i are making calls to one of the operator++ functions. Here's a standard pair of these functions:

Foo& Foo::operator++()   // called for ++i
{
this->data += 1;
return *this;
}

Foo Foo::operator++(int ignored_dummy_value) // called for i++
{
Foo tmp(*this); // variable "tmp" cannot be optimized away by the compiler
++(*this);
return tmp;
}

Since the compiler isn't generating code, but just calling an operator++ function, there is no way to optimize away the tmp variable and its associated copy constructor. If the copy constructor is expensive, then this can have a significant performance impact.

In C++ which is more EFFICIENT on non primitive types, A pre increment (++i) or a post increment (i++)

pre-increment (++i) is usually faster since post-increment returns the current value and then increments the value, whereas pre-increment just increments the variable.

In many situations a compiler will optimise this anyway, unless you are using post-increment specifically to use the current value and increment the value afterwards.

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

Executive summary: No.

i++ could potentially be slower than ++i, since the old value of i
might need to be saved for later use, but in practice all modern
compilers will optimize this away.

We can demonstrate this by looking at the code for this function,
both with ++i and i++.

$ cat i++.c
extern void g(int i);
void f()
{
int i;

for (i = 0; i < 100; i++)
g(i);

}

The files are the same, except for ++i and i++:

$ diff i++.c ++i.c
6c6
< for (i = 0; i < 100; i++)
---
> for (i = 0; i < 100; ++i)

We'll compile them, and also get the generated assembler:

$ gcc -c i++.c ++i.c
$ gcc -S i++.c ++i.c

And we can see that both the generated object and assembler files are the same.

$ md5 i++.s ++i.s
MD5 (i++.s) = 90f620dda862cd0205cd5db1f2c8c06e
MD5 (++i.s) = 90f620dda862cd0205cd5db1f2c8c06e

$ md5 *.o
MD5 (++i.o) = dd3ef1408d3a9e4287facccec53f7d22
MD5 (i++.o) = dd3ef1408d3a9e4287facccec53f7d22

Is ++x more efficient than x++ in Java?

It's not more efficient in Java. It can be more efficient in languages where the increment/decrement operators can be overloaded, but otherwise the performance is exactly the same.

The difference between x++ and ++x is that x++ returns the value of x before it was incremented, and ++x returns the value of x after it was incremented. In terms of code generation, both make up for the exact same number of instructions, at least when you can use either interchangeably (if you can't use them interchangeably, you shouldn't be worrying about which one is faster, you should be picking the one you need). The only difference is where the increment instruction is placed.

In C++, classes can overload both the prefix (++x) and postfix (x++) operators. When dealing with types that overload them, it is almost universally faster to use the prefix operator because the semantics of the postfix operator will return a copy of the object as it was before the increment, even when you wouldn't use it, while the prefix operator can simply return a reference to the modified object (and God knows C++ developers prefer to return references rather than copies). This could be a reason to consider ++x superior to x++: if you gain the habit of using ++x you could save yourself some slight performance trouble when/if you switch to C++. But in the context of Java only, both are absolutely equivalent.

Much like pst in the comments above, I never use the return value of x++ or ++x, and if you never do either, you should probably just stick to the one you prefer.



Related Topics



Leave a reply



Submit