Assignment operator - per member or binary copy?

Question

I was wondering, as long as all included assignments have no side effects except transferring a binary value to an address, isn't it more efficient to just copy the bytes from the source object pointer to the target instead of assigning each target member to each source member?

As a sub-question... I was wondering how does the reading mode influence the memory controller load. Obviously, it is most efficient when the MC reads its full width from properly aligned address. Maybe it will be more efficient to consolidate all members to a sequence of maximum wide datatypes for the alignment, e.g. if the MC is 64 bit and the member data set is 10 bytes, then copy a 64 bit and a 16 bit value, even if the members are say 10 chars, so copying this way will saturate the MC better than copying each member char at a time.

I'd prefer the `memcpy` over the assignment of each member. Assuming it can be `memcpy'd`. I consider this equivalent to having an array vs 10 individual variables. — Brandon, Apr 18 '14 at 21:16
If there's no side effects to copying the bits of each member, why do you even have an operator=? — Ben, Apr 18 '14 at 21:19
On x86/x64 platform assigning each members guarantees each member to be copied atomically (arch dependent e.g. int). The questions as I understand it is. Does assignment of entire thing preserve the same semantics. — user377178, Mar 22 '22 at 13:47

score 6 · Answer 1 · answered Apr 18 '14 at 21:17

As long as nothing but byte-copying is needed, just let the compiler generate the default one for you.
It will automagically optimize it too, using memcpy if that is most efficient.

As an added bonus, if you ever add a member with more complex (self-contained) semantics, the compiler will still do the right thing.

You only have to go in and do it yourself if you add a member which does not semantically copy its data.

score 0 · Answer 2 · answered Apr 18 '14 at 21:24

0

Generally speaking, memcpy will always be faster than per member copy. Some caveats:

memcpy will typically work in such a way that it will do aligned reads/writes whenever possible. However, that's a completely platform dependent thing, and memcpy could in theory be terribly inefficient
If the struct isn't aligned, then per-member copy will also require unaligned access
Packed structures are going to be slower, unless they are also aligned (like for SSE, NEON, etc)
memcpy will inevitably copy more bytes than necessary if the structure has padding in it.
The best way to determine the answer is to build, and run/profile it on the target machine, keeping in mind that different structs may have different characteristics.

answered Apr 18 '14 at 21:24

Brent

4,153
4
30
63

Why would you not let the compiler figure that out for you? Using memcpy is inherently dangerous and will not work for anything which is more than a glorified C-struct. – Jens Apr 18 '14 at 21:57
@Jens - you still have constructors in structs in C++ so actually it is only safe for C structs or basic POD, which is exactly the context of the question. It is exactly those trivial assignments I seek to optimize, I need explicit implementation, cannot just use the compiler default without knowing what it does. – Apr 18 '14 at 22:48
A POD cannot have constructors or an assignment operator, so you cannot memcpy your class, only the POD members. To answer your question if it is more efficient to use memcpy or the compiler-generated functions, you will have to measure. For safety, I would wrap memcpy in a function with a `static_assert( is_pod::value, "POD!")`. – Jens Apr 19 '14 at 07:00

score 0 · Answer 3 · answered Apr 18 '14 at 21:56

memcpy will only work for POD types. As soon as you have destructors, constructors, virtual functions, private data, inheritance, memcpy an object will be undefined behavior. So, it work for classes like

class PODType {
public:
    int x;
    int y;
};

class Object {
public:
    PODType m;
    Object& operator=(Object const& x) {
        memcpy(&m, x.m, sizeof(PODType));
        return *this;
    }
};

But now, as your program evolves, somebody changes PODType to have a custom constructor because it it convenient, or adds a destructor or does something else that makes it a non-POD. All classes memcpying it will now have undefined behavior. In these cases, it wil be best to use the compiler-generated assignment operator.

If you worry about performance,

Do not do premature optimization
Use a profiler and measure

Assignment operator - per member or binary copy?

3 Answers3