CODEWITHSUNDEEP
cperformanceoptimizationconstants
PhDP
PhDP

Reputation: 397

Is there a cost to "const"?

Compilers can sometime exploit the fact that some 'variable' is a constant for optimization, so it's generally a good idea to use the "const" keyword when you can, but is there a tradeoff?

In short, is there a situation where using "const" might actually make the code slower (even a tiny bit)?

Upvotes: 5

Views: 898

Answers (4)

Eli Iser
Eli Iser

Reputation: 2834

The const keyword is used only during compile-time. After the code is compiled the variable is just an address in the memory, without any special protection.

There is some difference, however - global const variables will be placed in the text segment, not the data (if initialized) or bss (if uninitialized). If the text segment is treated differently, for example executed in place from a NOR flash memory (instead of RAM), there might be a difference. Local const variables are placed on the stack together with the regular variables, so there should be no difference.

Other than that, as bestsss said, some compile time optimizations might be impossible if the variable is a constant. I can't really think of anything (especially not in pure C), but it is theoretically possible.

Edit:

The following code demonstrated the point in the second paragraph:

const int g = 1;
int not_const = 1;

void foo(int param)
{
    int i = 1;
    const int j = 1;

    printf("Variable: \t\t0x%08x\n", (int)&i);
    printf("Const varialbe: \t0x%08x\n", (int)&j);
    printf("Parameter: \t\t0x%08x\n", (int)&param);
    printf("Global const: \t\t0x%08x\n", (int)&g);
    printf("Global non-const: \t0x%08x\n", (int)&not_const);

}

In Visual Studio 2010, the result is as follows (note the big difference between the const and non-const global):

Variable: 0x002af444
Const varialbe: 0x002af440
Parameter: 0x002af43c
Global const: 0x00a02104
Global non-const: 0x00a03018

Upvotes: 10

Thomas Padron-McCarthy
Thomas Padron-McCarthy

Reputation: 27632

It is always possible for an optimizer to fail in various interesting ways, in this case and others. For example, I had a problem recently when the GCC optimizer replaced a memcmp call with a machine instruction. This was supposed to be faster, but on a 64-bit architecture it seems that this instruction was emulated, and it turned out to be slower than the explicitly coded loop inside memcmp.

Upvotes: 1

sharptooth
sharptooth

Reputation: 170489

A combination of "const" and "non-const" objects can hurt you badly in a rather unexpected way. Some pseudocode:

//in some file far far away...
SomeType firstVariable;
const SomeType secondVariable;

here these variables look like they are located at adjacent addresses.

On many architectures they will be located far from each other since "const" variables will be placed in a special segment that has write protection during runtime. So interleaved access to those variables will result in more chache misses than you expect and this can considerably slow your program down.

Upvotes: 4

sharptooth
sharptooth

Reputation: 170489

You can imagine an architecture where there's memory that is non-writable during program execution and accessing that memory is slower that accessing "usual" memory (because of extra checks during each access for example). This is highly unlikely - in most cases "const" will work at least as fast as "non-const".

Upvotes: 2

Related Questions