at what size should one call by reference..

Started by
14 comments, last by Lukas Boersma 18 years ago
Silly quasi-preformance question, but here goes: at about what size of a structure should one shift from calling by value to calling by reference? The reason one calls by value is that it gets copied to the stack which is faster to access than calling by reference which will access the heap, so typical example:

struct myStruct 
{
  /* data, but not so much data */
};


/*so which would be better: */

void myFunction(const struct myStruct *p_data)
/* C++ folk would use const struct myStruct &data*/

/* or */

void myFunction(const struct myStruct data)

at what size of myStruct (say on a modern PC) would be best to stick with call by value? -kRogue
Close this Gamedev account, I have outgrown Gamedev.
Advertisement
It depends on how you use the variable within the function. There is no easy answer, so just pick a convention and stick to it. Worst case, see how things are behaving in that function later, and make a decision based on actual use rather than conjecture.

CM
in the case I am concerned with at this moment, the data is a float matrix(4x4) so 16 floats, for a total of 64 bytes... the usage is basicly once for each object for each frame (of some 3D stuff)... me thinks I will make this one call by reference since it is passed along to an openGL API call which takes the data by reference anyways... but the more general case is still an important perfomance issue actually...
Close this Gamedev account, I have outgrown Gamedev.
My personal preference is basically whatever fits within a register on the target platform. For the most part, this is 32 bits.

In other words, almost all of my structures or classes are passed by pointer or reference. Only numeric types (integers, floating point, etc) are passed directly.

It's a coding habit I've carried over for the many years I worked with assembly and C. Can't seem to shake it. :)
Quote:Original post by bpoint
My personal preference is basically whatever fits within a register on the target platform. For the most part, this is 32 bits.

In other words, almost all of my structures or classes are passed by pointer or reference. Only numeric types (integers, floating point, etc) are passed directly.


It's the same with me. Now that I'm working almost exclusively with C++ with my personal projects, if I'm sending a pointer to some memory, or something that could possibly be not there that I can indicate with NULL, then I'll use a pointer. With most of my object's I'm using references because my objects are generally bigger than 4 bytes, or have a large amount of allocated memory which would have to be copied over to a new object if passed by value.
[size="2"][size=2]Mort, Duke of Sto Helit: NON TIMETIS MESSOR -- Don't Fear The Reaper
No, you're wrong with your example, c++ guys would use c++ not that c and c++ mixed thing you've written there.

Use by value for all built-ins and small PODs (8bytes and smaller) and of course use them too if you _need_ a copy. By reference if you have to change the value(s), or if the type(s) are non built-in types
I use, in the order of preference:
1) TYPE for PODs
2) const TYPE& by default
3) TYPE& for mutable arguments
4) TYPE*
5) TYPE

So if myFunction does not mutate your argument, use const myStruct&. Otherwise, use myStruct&.

hth,
CipherCraft
Quote:Original post by kRogue
...but the more general case is still an important perfomance issue actually...

Sure, but in the general case the performance question can't be answered.

CM
if (size > machine_word) use_reference;

Addendum: if (is_smart_pointer) use_const_reference;

[Edited by - _goat on March 28, 2006 9:02:27 AM]
[ search: google ][ programming: msdn | boost | opengl ][ languages: nihongo ]
I would add that size is not the only criterion for choosing between passing by reference or value. Constructor complexity is definitely a concern as well. For POD types, sure, constructor complexity is definined entirely by how many bytes need to be copied, so size is the only relevant factor. But outside of POD types, constructors could have all manner of different complexities. Usually size and complexity are roughly correlated, but not always.
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas only, and not for things themselves." - John Locke

This topic is closed to new replies.

Advertisement