0

I wanted to know if it is faster to normally return a value from a function or to use a pointer as a parameter and pass the value to that pointer.

  • It may be slow amount it is assigned separately also return value, but the difference is insignificant. It will become larger by the size of the struct in the case just like the return structure. – BLUEPIXY Feb 10 '14 at 14:16
  • You should first consider how much you use the data object, returning a pointer means allocating on the heap, and heap memory is slower to begin with. So returning a pointer may be faster in some cases, but if using that struct/object then is slower, and you use it a lot, your micro-optimization was counter productive. Passing a pointer to a stack variable in the calling function is probably faster... but that's a generalization that might not hold true in your case – Elias Van Ootegem Feb 10 '14 at 14:21
  • 1
    Profile your specific case. – Enigma Feb 10 '14 at 14:28
  • You have two horses. You wish to know which is faster. So you ask strangers on the internet which horse they think is faster? **Race your horses**. You can find out which one is faster by *trying it both ways with a stopwatch*. – Eric Lippert Feb 10 '14 at 23:54

5 Answers5

4

In different common ABIs, return-by-value for large (not fitting in registers) objects is implemented through a pointer anyways. The caller reserves the space, and passes a pointer to the callee, that uses that pointer to create the object in place.

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
  • Returning a `struct` is really a hidden `memcpy`, no? – Fiddling Bits Feb 10 '14 at 14:48
  • @FiddlingBits: It depends on the language, in C maybe (not a C expert) in C++ a `struct` and a class are the same thing and in most cases `memcpy` is not the correct thing to do and the compiler won't do it. in the Itanium ABI, a *large enough* `struct` is returned by value by means of the caller passing a hidden pointer and the callee creating the `struct` in place; as already stated in the answer. – David Rodríguez - dribeas Feb 10 '14 at 14:50
2

With modern Compilers and C++11 returning by value is fastest in many cases: Want Speed? Pass by Value. (Archive)

sigod
  • 3,514
  • 2
  • 21
  • 44
TNA
  • 2,595
  • 1
  • 14
  • 19
  • There's a [talk](https://www.youtube.com/watch?v=eR34r7HOU14) by Chandler Carruth that goes in depth of why it's faster to pass variables by value. – sigod Jan 23 '18 at 23:16
1

I will assume we're talking about C++11 here, since it's been 2.x years already.

Start by returning your object by value: move semantics, (N)RVO can kick in and generate really fast code that is really easy to read. However, if you profile your code and find that this particular function is a bottleneck, consider using a reference as an "out-parameter." This may in fact be faster than using a pointer, as the compiler has more flexibility with how to represent a reference. The ISO standard for C++ does not dictate that references require storage, so the compiler is free to make the reference a literal alias of the other memory location, using effectively zero bytes of overhead.

All in all though, write the cleanest code first, and then measure it. People underestimate just how much optimization the compiler can do for you if you just return your (movable) objects by value.

bstamour
  • 7,746
  • 1
  • 26
  • 39
0

Pointer is 4 or 8 bytes long depending on the architecture.

If your value is less that that in size, it might be faster to pass values.

If you have large objects and copy constructors, then more memory will be copied and passing that kind of parameters would be more expensive.

But... compiler optimizations, memory alignment, and other sorcery, might need you to directly investigate this in YOUR case.

Daniel Mošmondor
  • 19,718
  • 12
  • 58
  • 99
0

In return by value case, assume the caller has an object to pass the compiler will crate a copy of that argument which is more or less equivalent to the cost of pass by reference. So from performance point of view either solutions seems equivalent.

Sunil Bojanapally
  • 12,528
  • 4
  • 33
  • 46