13

Is accessing const variables faster than non-const variable? I'm wondering if it is worth using const more as a step in optimizing a program.

unwind
  • 391,730
  • 64
  • 469
  • 606
Theemathas Chirananthavat
  • 838
  • 1
  • 8
  • 27
  • You should do a benchmark on your own before asking such a question. – Björn Pollex Nov 29 '11 at 06:54
  • Is this from a test or something? – Chris Eberle Nov 29 '11 at 06:54
  • 12
    @BjörnPollex Why? Sure, a benchmark should be used before the questioner goes round changing code (this 'optimization' is unlikely to help), but to ask a question? Its an interesting question, and the likely futility of the optimization makes a valid answer. – Tom Nov 29 '11 at 06:59
  • There is value in `const` beyond possible performance: conveying your *intentions* to the next person who reads your code (which might be six-months-from-now you). – Steve Friedl May 24 '22 at 20:50

3 Answers3

18

If the value is a compile time constant (e.g. numbers, enum, const values, constexpr sometimes in c++11 and so on), then yes they can be accessed faster compared to other variables. They can even be placed in the code segment.

However, it's not true for any const:

const int x = 5;  // can be faster
const int c = foo(); // normal non-modfiable variable, normal speed

From the example you can see that, all non-modifiable variables are not compile time constants.

iammilind
  • 68,093
  • 33
  • 169
  • 336
  • Note that the latter can also be optimized in C++11, if `foo()` is a `constexpr`. – Björn Pollex Nov 29 '11 at 07:08
  • thanks, my program is like the second example.so no difference on speed,right? – Theemathas Chirananthavat Nov 29 '11 at 07:09
  • 1
    As a sidenote, there are some platform-dependent cases where a const is actually slower: on embedded systems where the const may reside in non-volatile, read-only memory. Accessing such memory can be slower than accessing variables in RAM. – Lundin Nov 29 '11 at 07:14
  • 1
    @BjörnPollex, earlier I wanted to add a case for `constexpr`. I have added now and is followed by `sometimes`. Because sometimes a `constexpr` [may not be a compile time constant](http://www.ideone.com/yyoNQ). – iammilind Nov 29 '11 at 07:16
  • Even the second definition may enable some optimizations, although less than the first one. For example, the compiler can assume that the value is not changed during function calls (because doing so would invoke undefined behaviour) and therefore if the value happens to be in a callee-saved register at a function call, there's no need to reload the value afterwards. With non-const variables, if there's the possibility that an outside function has access to it (a global variable, or a pointer/reference—even a const one—to it was passed to other functions) the compiler has to assume it changed. – celtschk Nov 29 '11 at 07:21
  • @Lundin is right, compiler may optimize, but assumptions may break for certain targets. – Prof. Falken Nov 29 '11 at 07:34
6

The answer to your question is maybe.

As Bjorn pointed out this question can only be answered by careful benchmarking because there are too many architecture specific reasons why the answer could be yes or no.

Here is a StackOverflow reference on benchmarking:

If you are working on a project where speed matters then the only way to really know what the compiler is doing and how it impacts speed is to read the generated assembly and perform careful benchmarking. Theorizing about what the compiler could do isn't productive. If you are working on an embedded system an oscilloscope is a great way to time things, on machines with more resources a high resolution timer provided by the OS is useful.

Community
  • 1
  • 1
Hucker
  • 671
  • 1
  • 8
  • 25
0
const int c =1;
int d = 1;
unsigned int e = 0;
start = std::chrono::steady_clock::now();

    for (int i = 100000000; i--;) {

        e += c;
        e -= c;

        e += c;
        e -= c;

        e += c;
        e -= c;

        e += c;
        e -= c;
    }


    end = std::chrono::steady_clock::now();
    time2 = std::chrono::duration_cast<std::chrono::duration<double>>(end - start);
    cout << time2.count() << endl;
    e = 0;
    start = std::chrono::steady_clock::now();

    for (int i = 100000000; i--;) {

        e += d;
        e -= d;

        e += d;
        e -= d;

        e += d;
        e -= d;

        e += d;
        e -= d;
    }
    end = std::chrono::steady_clock::now();
    time2 = std::chrono::duration_cast<std::chrono::duration<double>>(end - start);
    cout << time2.count() << endl;

Try this with the chrono libery and you will see that the code with const is faster. Const can make your code faster, but not everytime --> check this Fast Code with const ?

My Output of the Code above is -->

0.36604 //With const
0.416612
David
  • 11
  • 1