Premature Optimization

[Dan Eble]

On 2013-08-23, at 09:50 , David Kastrup <address@hidden> wrote:

> Frédéric Bron <address@hidden> writes:
>> 
>> Of course I am not speaking of new strings created in the function!
>> That would be stupid. But if you return a member of an object for
>> example, it is stupid to return a copy of it (I do not know if this
>> happens, however).
> 
> Not every object is persistent.  Again: references create life-time
> issues.  Messing with them, particularly in the case of a basic
> conceptually scalar data structure like "string" only makes some remote
> sense when there is positive proof that there is a serious performance
> impact for known implementations.

Two choices have been mentioned.  One is 

  1) void function(std::string);
  2) void function(const std::string&);

In my professional experience, we usually pass a structure by reference when it 
can't fit in a register. We always use (2) with strings that the function will 
not modify. We also pass smart pointers by const reference when the function 
will not create new references to the pointee.

Dangers of premature optimization:

  * wasting your resources on something ineffective because you haven't measured
  * harming performance because you haven't measured
  * harming maintainability without an offsetting benefit

Those don't apply. We know from experience that passing strings and smart 
pointers by value has been a problem. Passing by const reference improved 
performance and had little impact on maintainability. So, although it is true 
that most calls are not performance hot spots, this habit lets us spend our 
limited time worrying about other things. We don't want to be taught the same 
lesson many times.

The other choice is

  3) std::string getSomeMember() const;
  4) const std::string& getSomeMember() const;

Reasonable people might disagree, but IMHO this is premature optimization.  It 
is better to use (3), trust the compiler to do return value optimization, and 
wait for profiling to prove that there is any problem. I share David's concern 
that (4) can lead to bugs, and as above, not having to worry about those 
details frees a contributor to focus on the goal.

Regards,
-- 
Dan