kurt

Hello,

Let's say a function receives a structure that has 5 member variables. Each of the variables are used many times in this function.

Would it be more efficient to access the members time and time again (using the dot operator), or would it be better to access each of them for one time, by copying the value to 5 new variables in that function, which will then be used instead?

Creating new copy variables would make the code more readable as it is shorter without so many dot operations, but if performance is the objective, what would be the normal practice in the industry?

Thanks in advance.

DaWei

I presume you mean passing a reference to the struct. In that case, accessing the struct will require more addressing operations than accessing a copy of the member. For very many operations, this would outweigh the code necessary copy to the internal variables and then copy back.

If you mean passing the actual struct, copied struct members will be as readily accessible as a local variable copy, because the struct is essentially a local variable. This causes the additional problem of getting the modified local struct back into the 'real' struct.

To see this for yourself, you might want to examine the emitted code.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Narue

>if performance is the objective, what would be the normal practice in the industry?
The normal practice is not to optimize unless you have damn good reason to. That means measuring everything under the sun, then if the performance hit is so significant that you can warrant the development time of an optimization, go ahead and do it. Most of the time you won't end up optimizing because it's not worth it.

__________________
Even if the voices aren't real, they have some pretty good ideas.

SamReidHughes

There's one way I can think of in which, if the struct is a local copy, and not a reference, you might still benefit from keeping an extra copy of some variables. Suppose your struct has some functions that modify only some of the parameters. For example, vectors let you set elements, and that doesn't change the return value of size(). Unless the functions are inlinable, your compiler will have no way of knowing if the members have been modified, and maybe you'll have to access memory (or the processor cache) instead of a register. Which might cost you time. Might not.

I don't see why you would be asking this question, though. It's not usually going to make a significant difference in performance in any way that's worth sacrificing readability, and if it were an important difference, you'd be using experiments, not speculation, to maximize your performance.

DaWei

I don't consider it much of a readability issue, anyway, unless you name your local reference to the struct something atrociously long. MyStruct.varA make it obvious that the struct is being modified and reduces the chance of an error in moving the stuff into and out of temporary variables. The cost is a couple of instructions per modification.

You do want to avoid pre-optimization unless you're in a resource-tight situation, such as might be the case with an embedded application. Then you just write the tightest code you know how to write and optimize where necessary if the job doesn't get done.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

lectricpharaoh

To expand on this for the OP's benefit, leave it to the compiler. If you've got the appropriate optimizations enabled (ie, optimizing for speed rather than size), this sort of thing is taken care of. The compiler can see that you're making a lot of references to member variables, or using them in a loop, etc, and will (or will not, depending on the situation) make local copies (this is called 'aliasing' them).

Likewise, explicitly doing this sort of thing for clarity is a double-edged sword. Depending on the situation involved, it might actually make your code harder to follow.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Narue

>Depending on the situation involved, it might actually make your code harder to follow.
It might make it slower as well. Imagine how a processor will try to predict branches for you and usually be right if your machine code is written well, but if it's not written well there's a serious penalty for the failed prediction. Compilers use a heuristics-based approach toward optimization, and if your code is unconventional enough to sidestep those heuristics, you lose the optimization. Compiler writers go to a lot of trouble to optimize your code for you; you should take advantage of that.

__________________
Even if the voices aren't real, they have some pretty good ideas.