Re: [C++] Returning objects from a function and performance

From: Ulrich Eckhardt (doomster_at_knuut.de)
Date: 02/21/05 

Date: Mon, 21 Feb 2005 17:32:18 +0100

Spacen Jasset wrote:
> If I have a function that resturns a class object. i.e.
>
> ExtString mid( int start, int len )
> {
> ExtString result;
> ...
> return result;
> }
>
> Then the compiler must invoke the copy constructor of ExtString to make
> a copy and return it. Unless ofcourse it can be optimised. But surpose
> the function is like this:
>
> ExtString mid( int start, int len )
> {
> ExtString result1;
> ExtString result2;
>
> if ( /* something )
> return result1;
> else
> return result2;
> }
>
> The compiler would have a harder time optimising that I suspect.

Right.

> I ask this question becuase I've been told that this is all very
> inefficient and the 'mid' and other functions have been re-written in
> our library to take a refrence like this:
>
> void mid( ExtString &sub, int start, int len )
> {
> ...
> }

During runtime, it might be more efficient, but code tends to get less
readable. Also, with that method you can't initialise a [const] string
with the substring of another, so it's not a perfect solution either.
Maybe, since you implement it as a memberfunction anyway, you should
create a constructor that takes a string and a range?

Anyway, unless there is proof that you need to optimise and you know where
you can achieve the biggest improvements, you shouldn't. Of course, you
should not discard common sense, i.e. don't copy extremely large objects
more than necessary.

> Is returning a potentially large object from a function as bad as it
> seems?

Not necessarily. Many strings have copy-on-write backends that reduce the
copying overhead a lot already. A question to answer first is if this
happens often during the run of your program.

> It's still traditional amoung C programmers to never return structures
> by value, despite being able to do so officialy since C89. Presumably
> there is a considerable performance problem for large objects in C++,
> but perhaps notso in C since there are no copy constructors, and the
> compiler can avoid any object copy on return.

Right, C structures can basically be copied with memcpy(), while C++ copy
constructors can be much more complex, including dynamically allocating
memory.
BTW: I seem to remember a test that had the result that the border when
dynamic allocation and returning a pointer is faster than returning by
value is at ~400 bytes. Of course, this depends on the system, but is
probably much larger than most people would think.

Maybe what you are looking for is 'move constructors'. There are proposals
to introduce these into the language proper as well as a library called
MOJO that tries to achieve that with minimum intrusion. Google and you
will find both.

Uli 

-- 
FAQ: http://ma.rtij.nl/acllc-c++.FAQ.html