What is the overhead of link transfer?

Question

How expensive is access to a member variable when the getter in question returns a link?

for example, if you have a class that should use such an accessor quite often, how much more efficient will it be to store the specified link in the class that should use it and just initialize it once?

Answer 1

Regarding complexity, returning or passing a link is like passing a pointer. Its overhead is equivalent to passing an integer to the size of a pointer plus a few instructions. In short, it is as fast as possible in almost every case. A striking exception is the built-in types (e.g. int, float) that are less than or equal to the size of the pointer.

In the worst case, passing / returning a link may add some instructions or disable some optimizations. These losses rarely exceed the cost of returning / transferring objects at a cost (for example, calling the copy constructor + destructor is much higher, even for a very simple object). Passing / returning by reference is a good default if each instruction is not counted and you have measured this difference.

Therefore, the use of links has an incredibly low cost.

It is impossible to quantify how much faster it would be without knowing the complexity of your types and their constructor / destructor, but if it is not a built-in type, then saving the local one and returning it by reference will be the fastest in most cases - it all depends on the complexity of the object and copies of it, but only incredibly trivial objects can approximate link speed.

Answer 2

Get functions usually should not return links. The reason for this is that it makes access available to the user - if you want to do this, just make it a public user.

class foo { int bar; public: int& get_bar() { return bar; } // this is silly! Just make bar public! } 

Anyway, if it's as simple as get_bar , it will be bound to something like foo.bar . As Oli noted, you can also make it a reference to const, although for smaller types such as int , you have to go ahead and return by value.

With more expensive types, links are starting to be useful. You can assume that:

• The value of "overhead" is based on the amount of what you return.
• Reference "service data" based on the size of the link and the cost of dereferencing

For instance:

 foo x; x.get_value().func(); // calls copy constructor at least once and destructor x.get_reference().func(); // may require dereference when using 

Answer 3

If a function definition is accessible and relatively simple, then such a function becomes built-in, and there is no overhead compared to accessing a member directly. Otherwise, the sequence of operations will be as simple as obtaining the address of the class / structure object, applying the offset to get the address of the member, and returning this address to the caller. Now for these cases it makes sense to return by reference only if the object is not copied or its size is larger than the size of the pointer. The reason for the objects not being copied is obvious, otherwise you are looking at copying overhead — the size of the structure and the size of the pointer. Thus, this rule is to return large objects by reference (or pointer) and small objects (integers, doubles, etc.) by copying them. And in those cases when you do not need to control access rights to members of your deflection, just use structures with open access to members and do not inflate your code with many recipients and setters.

Answer 4

Honestly, if you start to wonder about these overheads: have you already thought about calling conventions using stdcall instead of cdecl?

The amount of speed you get from this is similar to what you talk about when discussing it.