Is it true that for built in types, pre increment and post increment have no effect on optimization?
i.e i++ and ++i does not optimize the code if "i" were an "int"?
I want to know :
1. what is difference from optimization point of view when u write "for" loop with i++ & ++i? (assume "i" is an int)
2. if in a statement I write ++i; instead of i++; does it optimize the code?
I think you'd be hard pushed to find a compiler that had a difference.
Even when you do, I'd say you'd be hard pushed to measure the difference.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
++i is not necessarily faster than i++ for built-in types. As standalone expressions, they do the same thing and any compiler that's worth a damn will produce the same machine code for both.
My best code is written with the delete key.
VC++6 used to produce different machine code for tiny examples in debug mode. Used the EAX register for the preincrement and the EDX for the postincrement.
++i is a good habit to get into, because it's often faster for custom types such as complicated iterators.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I've heard of prescript causing as much as an an 8% increase in speed on DevC++. That was on a program that had lots of loops.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Could it be with the postfix version instead?
All the prefix operator does is to increment the value and return the incremented object. Whereas the postfix version needs to store the incremented value and return the unchanged one.
Arguably the compiler optimizes away any differences, but for complex iterations, I would be lead to believe it's the postfix version the slowest.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
No, it was an increase in speed, not run time.Originally Posted by Mario F.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Yes. I misread it.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
well... post-increment can be seen as a function that stores the current value in a temporary, increments the value and returns the temporary.
so of course some compilers might not optimize that away - even on built in types.
signature under construction
The peephole optimiser (at least) should take care of the difference for built-in types. Of course many compilers might also perform a replace-postfix-with-prefix-where-possible optimisation at an earlier phase of compilation.
If you're a regular user of the standard C++ library, then using prefix for everything becomes the norm anyway, and there's no reason not to be consistent and use that for built-in types as well.
