++i vs i++

[Scoody]

I remember someone (MarauderIIC? ) always doing ++i instead of i++ in for-loop headers, so I thought I'd put it to the test with my newly acquired statistics knowledge ...
So I made this little cruncher to compare them (see attachment).
Here's some results running it on my computer with little or no CPU load

Code: Select all

++i vs. i++
 - the statistical approach
Incrementing...done
Post++
 X: 1.37e-007
 s: 1.17e-005
 ZInterval: [4.76e-008,2.27e-007]

++Pre
 X: 9.16e-008
 s: 9.57e-006
 ZInterval: [1.83e-008,1.65e-007]

ZTest result: ++i != i++

X = Expected time for increment
s = standard deviance
ZInterval is a range in which the time is 95% certain to fall between for the increment.
The ZTest tests if using i++ or ++i really matters, as you can see in my result, ++i wins. (5% chance to give wrong result)

I've noticed that under load the ZTest often gives the answer that using i++ is just as good as ++i, but mostly every run ++i ends up with the smallest amount of time.

[MarauderIIC]

IIRC, i++ makes a copy and increments it and then copies it back, because the value has to be available to use until the end of the statement. ++i modifies the original value. So ++i is always faster, except possibly for basic types such as int where the machine is optimized for such things.

[Falco Girgis]

IIRC, i++ makes a copy and increments it and then copies it back, because the value has to be available to use until the end of the statement. ++i modifies the original value. So ++i is always faster, except possibly for basic types such as int where the machine is optimized for such things.

Optimized? ++i is going to be faster no matter what optimization. There's still less required to not make a copy than there is to make a copy.

[MarauderIIC]

I guess I was trying to say that the handling of basic types is so fast that ++i vs i++ wouldn't be noticable. And a smart compiler might notice that basic type's i++ incremented value is not used and change it to ++i, like in a for loop, but it wouldn't necessarily do this with a user-defined type?

Edit: Further, integers and such benefit from value forwarding, assuming I remember my EE classes right, which would mean that the copy wouldn't be used, rather the incremented value is just used straight up. (Right?)

Obviously I'm almost out of my depth :)

Oh and

I remember someone (MarauderIIC? :)) always doing ++i instead of i++ in for-loop headers

Yeah, that's me. :)

[Scoody]

IIRC, i++ makes a copy and increments it and then copies it back, because the value has to be available to use until the end of the statement. ++i modifies the original value. So ++i is always faster, except possibly for basic types such as int where the machine is optimized for such things.

That sounds right, since that's how one would do it when overloading the operator.

I guess I was trying to say that the handling of basic types is so fast that ++i vs i++ wouldn't be noticable. And a smart compiler might notice that basic type's i++ incremented value is not used and change it to ++i, like in a for loop, but it wouldn't necessarily do this with a user-defined type?

Well, ++i "won" almost all my runs , but seeing that the time saved is miniscule (as you point out) it doesn't matter which one to use, but it's good for a habit when those user-defined types comes around.
Not that familiar with how the compiler would go around optimizing the increment, but it sounds reasonable, but anyway the numbers won't lie (unless I bugged the calculation...)

[LuciDreamTheater]

More on the topic:

http://www.parashift.com/c++-faq-lite/o ... #faq-13.15

[Falco Girgis]

And actually, there is a noticeable difference with integers when you get up into the thousands in loops. It's just a good practice.

[K-Bal]

IIRC, i++ makes a copy and increments it and then copies it back, because the value has to be available to use until the end of the statement. ++i modifies the original value. So ++i is always faster, except possibly for basic types such as int where the machine is optimized for such things.

Holy shit, I never thought about that :D

Today's lesson learned!