1

someone please tell me which one of the following is more fast and why ??

int add(int a, int b){
     return a+b;
}

OR

void add(int a, int *b){
     *b = a+(*b);
}
pb2q
  • 58,613
  • 19
  • 146
  • 147
Bond
  • 501
  • 2
  • 6
  • 18
  • 6
    This really shouldn't matter unless you're returning large structs and your compiler is completely impotent optimization-wise. – DCoder Jun 02 '12 at 04:32
  • 5
    Why do you *care*? The first function is obvious from its signature what it does and should be used. The second dereferences a raw pointer without checking it and should be discarded. If you *really* want to find out which is faster with your setup, *profile* them and compare your results. – johnsyweb Jun 02 '12 at 04:39

3 Answers3

5

Chances are functions are inlined and both result in the same generated code.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • 3
    If not, then I would expect the later version to be slightly slower assuming it has to dereference memory and cannot work solely with registers... – K-ballo Jun 02 '12 at 04:32
  • 1
    Why don't you add your comment in your answer itself.+1 – Prince John Wesley Jun 02 '12 at 04:34
  • 1
    @Prince John Wesley: Because if the compiler can't _inline_ such a simple function, then there is no point in trying to optimize anything. – K-ballo Jun 02 '12 at 04:36
  • What code are you referring to in regards to the undefined behavior? – Benjamin Lindley Jun 02 '12 at 04:39
  • @Benjamin Lindley: `*b = a+(*b);` I'm unsure whether there is a _sequence point_ or not at `=`, but I believe there isn't any... Can you confirm (or deny) this? – K-ballo Jun 02 '12 at 04:40
  • Thank you for replying.Actually I just used this function for an example. I have complex calculations as function body. I have to return long double from the function. the function is not inline. – Bond Jun 02 '12 at 04:43
  • @Bond: Just return the long double. – K-ballo Jun 02 '12 at 04:45
  • @K-ballo: I'm not an expert on the sequence point stuff, but if the expression `x=x+y` is undefined behavior, then I quit. – Benjamin Lindley Jun 02 '12 at 04:46
  • @Benjamin Lindley: Yeah, that's what makes me doubt and believe is not undefined behavior after all. But apparently `i = i++` is... – K-ballo Jun 02 '12 at 04:48
  • sorry but long doubles are class variables and I have to return a class having 5 long double variables. thats why I though if I can any how speed up my process. – Bond Jun 02 '12 at 04:50
  • @K-ballo please tell me what do you mean by undefined behaviour ?? – Bond Jun 02 '12 at 04:54
  • @K-ballo: "*Sequence points also come into play when the same variable is **modified** more than once within a single expression.*" `i = i++` *modifies* `i` twice, this example modifies `*b` only once. At least that's my understanding. – DCoder Jun 02 '12 at 05:04
  • @Bond even if you return large objects, the compiler is likely to optimize copies away. See my answer below. – juanchopanza Jun 02 '12 at 06:23
2

You should not try to guess which one is faster by looking at code, but profile the options under consideration to see whether one is faster than the other, andwhether it really makes a difference. Now concerning your example, I think returning by value is no problem at all, since most compilers these days perform return value and named return value optimzation, which are forms of copy elision. On top of that, C++11 introduces move semantics, which means that, where applicable, data is "moved" from a temporary to a target. So in fact, it may be faster to return by value, since you do not have to check the inputs.

For a related discussion on passing by value, see here, and for a related question, see here.

Community
  • 1
  • 1
juanchopanza
  • 223,364
  • 34
  • 402
  • 480
0

It is very unlikely that returning a value is slower than saving it as values are normally returned in registers (typically the accumulator if the CPU has one and the return value will fit).

Dipstick
  • 9,854
  • 2
  • 30
  • 30