C++ performance of accessing member variables versus local variables

Question

Is it more efficient for a class to access member variables or local variables? For example, suppose you have a (callback) method whose sole responsibility is to receive data, perform calculations on it, then pass it off to other classes. Performance-wise, would it make more sense to have a list of member variables that the method populates as it receives data? Or just declare local variables each time the callback method is called?

Assume this method would be called hundreds of times a second...

In case I'm not being clear, here's some quick examples:

// use local variables
class thisClass {
    public:
        void callback( msg& msg )
        {
            int varA;
            double varB;
            std::string varC;
            varA = msg.getInt();
            varB = msg.getDouble();
            varC = msg.getString();

            // do a bunch of calculations
         }

};

// use member variables
class thisClass {
    public:
        void callback( msg& msg )
        {
             m_varA = msg.getInt();
             m_varB = msg.getDouble();
             m_varC = msg.getString();

             // do a bunch of calculations
        }

    private:
        int m_varA;
        double m_varB;
        std::string m_varC;

};

Answer 1

Executive summary: In virtually all scenarios, it doesn't matter, but there is a slight advantage for local variables.

Warning: You are micro-optimizing. You will end up spending hours trying to understand code that is supposed to win a nanosecond.

Warning: In your scenario, performance shouldn't be the question, but the role of the variables - are they temporary, or state of thisClass?

Warning: First, second and last rule of optimization: measure!

---

First of all, look at the typical assembly generated for x86 (your platform may vary):

// stack variable: load into eax
mov eax, [esp+10]

// member variable: load into eax
mov ecx, [adress of object]
mov eax, [ecx+4]

Once the address of the object is loaded, int a register, the instructions are identical. Loading the object address can usually be paired with an earlier instruction and doesn't hit execution time.

But this means the ecx register isn't available for other optimizations. However , modern CPUs do some intense trickery to make that less of an issue.

Also, when accessing many objects this may cost you extra. However , this is less than one cycle average, and there are often more opprtunities for pairing instructions.

Memory locality: here's a chance for the stack to win big time. Top of stack is virtually always in the L1 cache, so the load takes one cycle. The object is more likely to be pushed back to L2 cache (rule of thumb, 10 cycles) or main memory (100 cycles).

However , you pay this only for the first access. if all you have is a single access, the 10 or 100 cycles are unnoticable. if you have thousands of accesses, the object data will be in L1 cache, too.

In summary, the gain is so small that it virtually never makes sense to copy member variables into locals to achieve better performance.

Answer 2

I'd prefer the local variables on general principles, because they minimize evil mutable state in your program. As for performance, your profiler will tell you all you need to know. Locals should be faster for ints and perhaps other builtins, because they can be put in registers.

Answer 3

This should be your compilers problem. Instead, optimize for maintainability: If the information is only ever used locally, store it in local (automatic) variables. I hate reading classes littered with member variables that don't actually tell me anything about the class itself, but only some details about how a bunch of methods work together :(

In fact, I would be surprised if local variables aren't faster anyway - they are bound to be in cache, since they are close to the rest of the functions data (call frame) and an objects pointer might be somewhere totally else - but I am just guessing here.

Answer 4

Silly question.
It all depends on the compiler and what it does for optimization.

Even if it did work what have you gained? Way to obfuscate your code?

Variable access is usually done via a pointer and and offset.

• Pointer to Object + offset
• Pointer to Stack Frame + offset

Also don't forget to add in the cost of moving the variables to local storage and then copying the results back. All of which could be meaning less as the compiler may be smart enough to optimize most of it away anyway.

Answer 5

A few points that have not been mentioned explicitly by others:

• You are potentially invoking assignment operators in your code. eg varC = msg.getString();

• You have some wasted cycles every time the function frame is setup. You are creating variables, default constructor called, then invoke the assignment operator to get the RHS value into the locals.

• Declare the locals to be const-refs and, of course, initialize them.

• Member variables might be on the heap(if your object was allocated there) and hence suffer from non-locality.

• Even a few cycles saved is good - why waste computation time at all, if you could avoid it.

Answer 6

When in doubt, benchmark and see for yourself. And make sure it makes a difference first - hundreds of times a second isn't a huge burden on a modern processor.

That said, I don't think there will be any difference. Both will be constant offsets from a pointer, the locals will be from the stack pointer and the members will be from the "this" pointer.

Answer 7

In my oppinion, it should not impact performance, because:

• In Your first example, the variables are accessed via a lookup on the stack, eg [ESP]+4 which means current end of stack plus four bytes .
• In the second example, the variables are accessed via a lookup relative to this (remember, varB equals to this->varB). This is a similar machine instruction.

Therefore, there is not much of a difference.

However, You should avoid copying the string ;)

Answer 8

The amount of data that you will be interacting with will have a bigger influence on the execution speed than the way you represent the data in the implementation of the algorithm.

The processor does not really care if the data is on the stack or on the heap (apart from the chance that the top of the stack will be in the processor cache as peterchen mentioned) but for maximum speed, the data will have to fit into the processor's cache (L1 cache if you have more than one level of cache, which pretty much all modern processors have). Any load from L2 cache - or $DEITY forbid, main memory - will slow down the execution. So if you're processing a string that's a few hundred KB in size and chances on every invocation, the difference will not even be measurable.

Keep in mind that in most cases, a 10% speedup in a program is pretty much undetectable to the end user (unless you manage to reduce the runtime of your overnight batch from 25h back to less than 24h) so this is not worth fretting over unless you are sure and have the profiler output to back up that this particular piece of code is within the 10%-20% 'hot area' that has a major influence over your program's runtime.

Other considerations should be more important, like maintainability or other external factors. For example if the above code is in heavily multithreaded code, using local variables can make the implementation easier.

Answer 9

It depends, but I expect there would be absolutely no difference.

What is important is this: Using member variables as temporaries will make your code non-reentrant - For example, it will fail if two threads try to call callback() on the same object. Using static locals (or static member variables) is even worse, because then your code will fail if two threads try to call callback() on any thisClass object - or descendant.

Answer 10

Using the member variables should be marginally faster since they only have to be allocated once (when the object is constructed) instead of every time the callback is invoked. But in comparison to the rest of the work you're probably doing I expect this would be a very tiny percentage. Benckmark both and see which is faster.

Answer 11

Also, there's a third option: static locals. These don't get re-allocated every time the function is called (in fact, they get preserved across calls) but they don't pollute the class with excessive member variables.