Thread: does const make functions faster?

Hi,

Usually when I am writing some code, I do not use const (I have now realized that may be I should . So one of my functions could look like this:

Code:

void setSpeed(float NewSpeed) {Speed=NewSpeed;}

Then I just put a const modifier before float NewSpeed:

Code:

void setSpeed(const float NewSpeed) {Speed=NewSpeed;}

I understand that it tells the compiler that NewSpeed will never be changed during the execution of the function. But would it make the function faster? Or: will NewSpeed occupy less memory?

And:

Code:

//will this
float getSpeed() const {return Speed;}

//be faster than this:
float getSpeed() {return Speed;}

What about the 'mutable' modifier? Will it make a function faster? I have really never seen mutable being used in regular code. Why is that?

thnx in advance

I understand that it tells the compiler that NewSpeed will never be changed during the execution of the function.

Yes, and const actually prevents your program from compiling if the function does try to change the parameter. You should use const whenever you can because without the const modifier, it's possible for your program to compile, yet your function surreptitiously changes the parameter without you knowing it. Obviously, in your simple function that isn't going to happen without your seeing it, but in a complicated function, you might not be able to discern that the parameter is being changed contrary to your wishes. With the const modifier in there, the compiler will alert you to any changes your function tries to make to the parameter, and you can fix your code.

But would it make the function faster?

I would think the const modifier would make a program compile slower since the compiler would have to check to see if the parameter was modified in the function, but I think execution speed would be exactly the same since no checking would be required--the compiler already verified the code does not change the parameter.

mutable provides an exemption to const, and I don't think there are many situations where that comes up.

A parameter that is not a reference or pointer is a copy of the original value. You can modify it whatever you like. Making it const might, but is unlikely to, help the compiler with optimization in the general case. However, it would help a compiler with inlining, because if it knows a variable is not modified, then it does not need to create a copy for the inlined function. However, the benefit of this is actually doubtful, because the compiler should also be able to see if the variable gets modified. If it isn't, then the function is likely so complicated that it won't be inlined anyway.

Making whole member functions const, on the other hand, is not a matter of optimization, but more a matter of being able to call that function on a const object.

A set function like that ought to take a const reference. This forces you not to change it, and it increases speed, for instead of creating a copy, it references the parameter directly.

Whether this increases speed significantly depends on what you're passing. If it's just one int or float, you probably won't see any notable difference. But as one of my professors likes to say, "If you're moving school buses around, then you want to use a const reference."

Originally Posted by 7stud

So, if I understand you correctly, you are saying if you do pass by value, and you use the const modifier, then in an effort to optimize, the compiler won't actually pass by value, and it will pass by reference?

The compiler won't pass at all, because the compiler will inline the function, i.e. replace the function call by the function's code.

Here's an example, a simple setter.

Code:

class Example
{
  int a_, b_;
public:
  void setA(int a) {
    a_ = a;
  }
  void setB(const int b) {
    b_ = b;
  }
};

int main()
{
  int my = 10;
  Example e;
  e.setA(my);
  e.setB(my);
}

Without inlining, the whole thing looks like this:
my is created. Space is allocated and 10 written there.
e is created. Thus, space is allocated for a_ and b_.
setA is called and my is passed. This means that first, a little space on the stack is allocated and my is copied there. Then the execution jumps to setA. The little space just allocated is known as a. Because a is not const, it can be modified. The function, however, doesn't modify it but instead reads the value there and writes it to a_. When the function returns, the space of a is freed and forgotten about.
setB is called and my is passed. This means that again, a little space on the stack is allocated and my is copied there. Within setB, this space will be known as b. Execution jumps to setB. b is const, which means nothing at runtime, but makes the compiler give error messages on attempts to modify b in setB. setB doesn't, however. It just reads it and writes the value to b_.

With inlining, the story gets more complicated. Inlining, as I said, means replacing the function call with the actual function code.
When an inlined setB is called, the situation is simple. The parameter, b, is guaranteed not to be modified, so there's no need to create a copy of my. The resulting code simply writes the value of my to b_.
An inlined setA is allowed to modify a. Thus, the compiler needs to create a copy of my so that, if setA actually modifies it, my stays untouched.
In this situation, const is faster.
However, setA is very simple. As such, the compiler can recognize that a is never modified despite the permission to do so, so it will still not make a copy. The speed advantage is lost.

When objects with non-trivial copy constructors are involved, the copy must be made regardless of const or not, if only to invoke the copy constructor. The problem here is that the cc could have side effects so the call may not be optimized away. (That's because a is a named object and the special return value exception clause does not apply.)