Should I use const for local variables for better code optimization?

Question

I often use const for local variables that are not being modified, like this:

const float height = person.getHeight();

I think it can make the compiled code potentially faster, allowing the compiler to do some more optimization. Or am I wrong, and compilers can figure out by themselves that the local variable is never modified?

Answer 1

Or am I wrong, and compilers can figure out by themselves that the local variable is never modified?

Most of the compilers are smart enough to figure this out themselves.
You should rather use const for ensuring const-correctness and not for micro-optimization.
const correctness lets compiler help you guard against making honest mistakes, so you should use const wherever possible but for maintainability reasons & preventing yourself from doing stupid mistakes.

It is good to understand the performance implications of code we write but excessive micro-optimization should be avoided. With regards to performance one should follow the,

80-20 Rule:

Identify the 20% of your code which uses 80% of your resources, through profiling on representative data sets and only then attempt to optimize those bottlenecks.

Answer 2

This performance difference will almost certainly be negligible, however you should be using const whenever possible for code documentation reasons. Often times, compilers can figure this out for your anyway and make the optimizations automatically. const is really more about code readability and clarity than performance.

Answer 3

If there is a value type on the left hand, you may safely assume that it will have a negligible effect, or none at all. It's not going to influence overload resolution, and what is actually const can easily be deduced from the scope.

---

It's an entirely different matter with reference types:

std::vector<int> v(1);
const auto& a = v[0];
auto& b = v[0];

These two assignments resolve to two entirely different operators, and similar overload pairs are found in many libraries aside STL too. Even in this simple example, optimizations which depend on v having been immutable for the scope of b are already no longer trivial and less likely to be found.

The STL is still quite tame in these terms though, in such that at least the behavior doesn't change based on choosing the const_reference overload or not. For most of STL, the const_reference overload is only tied to the object being const itself.

Some other libraries (e.g. Qt) make heavy use of copy-on-write semantics. In these const-correctness with references is no longer optional, but necessary:

QVector<int> v1(1);
auto v2 = v1; // Backing storage of v2 and v1 is still linked
const auto& a = v1[0]; // Still linked
const auto& b = v2[0]; // Still linked
auto& c = v2[0]; // Deep copy from v1 to v2 is happening now :(
// Even worse, &b != &c

Copy-on-write semantics are something commonly found in large-matrix or image manipulation libraries, and something to watch out for.

It's also something where the compiler is no longer able to save you, the overload resolution is mandated by C++ standard and there is no leeway for eliminating the costly side effects.

Answer 4

I don't think it is a good practice to make local variables, including function parameters, constant by default.

The main reason is brevity. Good coding practices allow you to make your code short, this one doesn't.

Quite similarly, you can write void foo(void) in your function declarations, and you can justify it by increased clarity, being explicit about not intending to pass a parameter to the function, etc, but it is essentially a waste of space, and eventually almost fell out of use. I think the same thing will happen to the trend of using const everywhere.

Marking local variables with a const qualifier is not very useful for most of the collaborators working with the code you create. Unlike class members, global variables, or the data pointed to a by a pointer, a local variable doesn't have any external effects, and no one would ever be restricted by the qualifier of the local variable or learn anything useful from it (unless he is going to change the particular function where the local variable is).

If he needs to change your function, the task should not normally require him to try to deduce valuable information from the constant qualifier of a variable there. The function should not be so large or difficult to understand; if it is, probably you have more serious problems with your design, consider refactoring. One exception is functions that implement some hardcore math calculations, but for those you would need to put some details or a link to the paper in your comments.

You might ask why not still put the const qualifier if it doesn't cost you much effort. Unfortunately, it does. If I had to put all const qualifiers, I would most likely have to go through my function after I am done and put the qualifiers in place - a waste of time. The reason for that is that you don't have to plan the use of local variables carefully, unlike with the members or the data pointed to by pointers.

They are mostly a convenience tool, technically, most of them can be avoided by either factoring them into expressions or reusing variables. So, since they are a convenience tool, the very existence of a particular local variable is merely a matter of taste.

Particularly, I can write:

• int d = foo(b) + c;
• const int a = foo(b); int d = a + c;
• int a = foo(b); a += c

Each of the variants is identical in every respect, except that the variable a is either constant or not, or doesn't exist at all. It is hard to commit to some of the choices early.

Answer 5

There is one major problem with local constant values - as shown in the code below:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

// const uint32_t const_dummy = 0;

void func1(const uint32_t *ptr);

int main(void) {
    const uint32_t const_dummy = 0;
    func1(&const_dummy);
    printf("0x%x\n", const_dummy);
    return EXIT_SUCCESS;
}

void func1(const uint32_t *ptr) {
    uint32_t *tmp = (uint32_t *)ptr;
    *tmp = 1;
}

This code was compiled on Ubuntu 18.04.

As you can see, const_dummy's value can be modified in this case! But, if you modify the code and set const_dummy scope to global - by commenting out the local definition and remove the comment from the global definition - you will get an exception and your our program will crash - which is good, because you can debug it and find the problem.

What is the reason? Well global const values are located in the ro (read only) section of the program. The OS - protects this area using the MMU. It is not possible to do it with constants defined in the stack.

With systems that don't use the MMU - you will not even "feel" that there is a problem.