Lol

[Valmont]

For C++ programmers:

According to Microsoft the prefix iterator ++ is faster then the postfix version.
So ++i is faster then i++.

I've tested this. Let me present the code first.

 // PerformanceCheck.cpp : Defines the entry point for the console application.
//

#include "stdafx.h" //Holds <iostream.h>, <time.h>

long double i = 0;

int main(int argc, char* argv[])
{
	clock_t start, end;
	long double duration;
	start=clock();
	for(i;i<4000000000;i++)
	{i++;}
	end=clock();
	duration=(long double)(end-start)/CLOCKS_PER_SEC;
	cout<<"Elapsed time: "<<duration<<endl;

	return 0;	
}

Check out "i". This loop (four billion!) executes "i++" (and ++i) only.

In the code, I take the time before the loop starts and after the loop ends.
Result on my 2GHz machine:
i++: between 11.093 seconds and 11.125 seconds.
++i: EXACTLY the same.
Test repeats: 1000.
*.exe mode: release, optimization for speed. One thread.

Congratulation Microsoft in fooling tons of programmers.

Why did I test this?
I am currently involved in a beta testers group for BattleZone2 1.3b. The lead programmer added a comment that he changed all instances of "i++" to "++i" because MS said it is slightly faster. Luckily the programmer said he doesn't trust MS but he managed to change all the instances without testing!!

ROFL. As soon as the BZ2 boards are up again ima gonna post this hehe

[sde]

hah!

[alpha]

lol..

and i thought it was faster.. but i haven't tested it. i guess if it is, it isn't noticably so..

[redhead]

In theory it should be slightly faster, given that the postfix operator will make the earlier value of your itterator available for use in the same line. Where as the prefix operator changes the value instantly.
If you made some serius compiler optimization on that, you might end up with saving one or two instructions in the assembly code.. But then again, that'll be one clock-cycle in a 2Ghz CPU.. Not that much anyway.

[Valmont]

It might be that a prefix increment adds a value first, but this is useless in a loop. I the end the fully executed loop takes 5 clock cycles to execute.

Lets find out more about this. Maybe it is relevant in nano-second timing programs.

[Unicorn]

I tried a few situations with gcc 3.2, it seems that for builtin types the prefix and postfix increment operator result in exactly the same assembly code.

For other iterators (e.g. STL), it depends on the kind of iterator and the optimization flags you use. In some cases there is no difference, in some cases prefix is faster.

I don't see any reason to use postfix.

[Valmont]

I've promised to find out more about this, so I did:

There is a difference in the interface (code) between post and pre increment operators in certain data types.
The post increment does create a temporary variable and the temp var might call the constructor of it's class for it's instance. This slows down the execution time.
So to prevent this (creating the temp variable) one should use the pre increment to make sure no un-needed constructor calls are made.

Remember that constructor calls are slow and destructor calls are even slower. Those are the basics, but always handy to to write down again .

Phew, another lesson learned .

[killemov]

I just stumbled onto this thread ... (bit late)

	for(i;i<4000000000;i++)
	{i++;}

the problem is of course in incrementing i inside the loop. If you do not touch the loop iterator, using the prefix incrementor will be optimized better.

[Valmont]

It still doesn't matter. No temporaries are made so this doesn't have any effect.
It will matter where a post-increment creates a temporary.

...using the prefix incrementor will be optimized better.

Assembly code wise not at all.

[teknomage1]

Isn't blithely changing all post increments to preincrements a recipe for subtle bugs, if the original programmer was counting on seeing the old value then incrementing?

[Valmont]

Well in that case you shouldn't change it.
But in loops usually you should use the pre-increment. Although with built in types it doesn't matter. That I did test.