Question

In a programme I am writing, I have to pass large data structures (images) between functions. I need my code to be as fast as possible, on different OSs (thus, I can’t profile all test cases). I frequently have code of the form…

void foo() {
  ImageType img = getCustomImage();
}

ImageType getCustomImage() {
  ImageType custom_img;
  //lots of code
  return custom_img;
}

AFAIK, the line ImageType img = getCustomImage(); will result in a copy constructor being called for img with the return value from custom_img as its parameter. Wikipedia says that some compilers will even do this operation again, for an initial temporary variable!

My question: Is it faster in general to thus bypass this overhead (copy constructors for images are expensive) by using pass by reference rather than a return value…

void foo() {
  ImageType img;
  getCustomImage(img);
}

void getCustomImage(ImageType &img) {
  //code operating directly on img
}

I’ve been told that if the compiler supports return value optimisation then there should be no difference. Is this true? can I (within reason) assume this nowadays, and how should I structure my programmes when speed is important

Answer 1

You should write code that is maintainable, compilers are really good at doing the right thing for performance in most cases. If you feel that things go slowly, then measure the performance and after you have located the bottleneck, try to figure out how to improve it.

You are right in that logically the code triggers different copy constructions: from custom_img to the returned temporary and then to the img object in the caller code, but the fact is that both copies will be elided.

In the particular case of return by value versus default-construct + pass-by-reference, all calling conventions that I know of implement return by value by having the caller allocate the memory and pass a hidden pointer to the callee, which effectively implements what you would be trying to do. So from a performance point of view, they are basically equivalent.

I wrote about this (value semantics in function arguments and return values) in the past in this two blog entries:

• Named Return Value Optimization
• Copy Elision

EDIT: I have intentionally avoided the discussion of the cases where NRVO cannot be applied by the compiler, the reason being that any function f that can take a reference to the object for processing: void f( T & out ) { /* code */ } can be trivially convertible to a function where NRVO is trivial for the compiler to implement that returns by value by a simple transformation into: T f() { T out; /* code */ return out; }