Is there any performance difference between for() and while()?

Short answer: no, they are exactly the same.

Guess it could in theory depend on the compiler; a really broken one might do something slightly different but I'd be surprised.

Just for fun here are two variants that compile down to exactly the same assembly code for me using x86 gcc version 4.3.3 as shipped with Ubuntu. You can check the assembly produced on the final binary with objdump on linux.

int main()
{
#if 1
    int i = 10;
    do { printf("%d\n", i); } while(--i);
#else
    int i = 10;
    for (; i; --i) printf("%d\n", i);
#endif
}

EDIT: Here is an "oranges with oranges" while loop example that also compiles down to the same thing:

    while(i) { printf("%d\n", i); --i; }

I write compilers. We compile all "structured" control flow (if, while, for, switch, do...while) into conditional and unconditional branches. Then we analyze the control-flow graph. Since a C compiler has to deal with general goto anyway, it is easiest to reduce everything to branch and conditional-branch instructions, then be sure to handle that case well. (A C compiler has to do a good job not just on handwritten code but also on automatically generated code, which may have many, many goto statements.)

Is while() faster/slower than for()? Let's review a few things about optimization:

• Compiler-writers work very hard to shave cycles by having fewer calls to jump, compare, increment, and the other kinds of instructions that they generate.

• Call instructions, on the other hand, consume many magnitudes more cycles, but the compiler is nearly powerless to do anything to remove those.

• As programmers, we write lots of function calls, some because we mean to, some because we're lazy, and some because the compiler slips them in without being obvious.

• Most of the time, it doesn't matter, because the hardware is so fast, and our jobs are so small, that the computer is like a beagle dog who wolfes her food and begs for more.

• Sometimes, however, the job is big enough that performance is an issue.

• What do we do then? Where's the bigger payoff?

  • Getting the compiler to shave a few cycles off loops & such?
  • Finding function calls that don't -really- need to be done so much?

• The compiler can't do the latter. Only we the programmers can.

• We need to learn or be taught how to do this. It doesn't come naturally. We are congenitally inclined to make wrong guesses and then bet on them. Getting better algorithms is a start, but only a start. Our teachers need to teach this, if indeed they know how.

• Profilers are a start. I do this.

The apocryphal quote of Willie Sutton when asked Why do you rob banks?:
Because that's where the money is.

If you want to save cycles, find out where they are.