views:

403

answers:

10

I'm just curious and can't find the answer anywhere. Usually, we use an integer for a counter in a loop, e.g. in C/C++:

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

But we can also use a short integer or even a char. My question is: Does it change the performance? It's a few bytes less so the memory savings are negligible. It just intrigues me if I do any harm by using a char if I know that the counter won't exceed 100.

+1  A: 

No, it really shouldn't impact performance.

Daniel A. White
+9  A: 

Probably using the "natural" integer size for the platform will provide the best performance. In C++ this is usually int. However, the difference is likely to be small and you are unlikely to find that this is the performance bottleneck.

1800 INFORMATION
It does sometimes happen though. On a recent title the profiler told me that we were spending 7% of CPU inside the iterator for a ubiquitous container class. On investigation I found that it was using a short for its index type; changing it to an int knocked that function below 1%.
Crashworks
+1  A: 

It probably would have been quicker to type in a quick program (you did the most complex line already) and profile it, than ask this question here. :-)

FWIW, in languages that use bignums by default (Python, Lisp, etc.), I've never seen a profile where a loop counter was the bottleneck. Checking the type tag is not that expensive -- a couple instructions at most -- but probably bigger than the difference between a (fix)int and a short int.

Ken
+1  A: 

Probably not as long as you don't do it with a float or a double. Since memory is cheap you would probably be best off just using an int.

GameFreak
+2  A: 

I can't provide a citation, but I've heard that you often do incur a little performance overhead by using a short or char.

The memory savings are nonexistant since it's a temporary stack variable. The memory it lives in will almost certainly already be allocated, and you probably won't save anything by using something shorter because the next variable will likely want to be aligned to a larger boundary anyway.

Peter
+2  A: 

You can use whatever legal type you want in a for; it doesn't have to be integral or even built in. For example, you can use iterators as well:

for( std::vector<std::string>::iterator s = myStrings.begin(); myStrings.end() != s; ++s )
{
...
}

Whether or not it will have an impact on performance comes down to a question of how the operators you use are implemented. So in the above example that means end(), operator!=() and operator++().

John Dibling
+3  A: 

Depends on the architecture. On the PowerPC, there's usually a massive performance penalty involved in using anything other than int (or whatever the native word size is) -- eg, don't use short or char. Float is right out, too.

You should time this on your particular architecture because it varies, but in my test cases there was ~20% slowdown from using short instead of int.

Crashworks
+1  A: 

An unsigned or size_t should, in theory, give you better results ( wow, easy people, we are trying to optimise for evil, and against those shouting 'premature' nonsense. It's the new trend ).

However, it does have its drawbacks, primarily the classic one: screw-up.

Google devs seems to avoid it to but it is pita to fight against std or boost.

rama-jka toti
On what architectures would unsigned give better results?
Steve Jessop
+2  A: 

This is not really an answer. I'm just exploring what Crashworks said about the PowerPC. As others have pointed out already, using a type that maps to the native word size should yield the shortest code and the best performance.

$ cat loop.c
extern void bar();

void foo()
{
    int i;

    for (i = 0; i < 42; ++i)
        bar();
}

$ powerpc-eabi-gcc -S -O3 -o - loop.c
.
.
.L5:
        bl bar
        addic. 31,31,-1
        bge+ 0,.L5

It is quite different with short i, instead of int i, and looks like won't perform as well either.

.L5:
        bl bar
        addi 3,31,1
        extsh 31,3
        cmpwi 7,31,41
        ble+ 7,.L5
sigjuice
A: 

If you compile your program with optimization (e.g., gcc -O), it doesn't matter. The compiler will allocate an integer register to the value and never store it in memory or on the stack. If your loop calls a routine, gcc will allocate one of the variables r14-r31 which any called routine will save and restore. So use int, because that causes the least surprise to whomever reads your code.