Re: [boost] Constructing string_ref from rvalue string

Subject: Re: [boost] Constructing string_ref from rvalue string
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-03-24 02:08:22

On 24/03/2017 12:42, Bo Persson wrote:
> On 2017-03-23 22:46, Gavin Lambert wrote:
>> On 23/03/2017 20:57, Olaf van der Spek wrote:
>>> AFAIK string_ref should be passed by value, not by const&.
>>
>> It's larger than a pointer.  Ergo, pass by reference.
>>
>> Granted it doesn't make a lot of difference as it's trivial to copy so
>> that performance isn't much of an issue, but why waste stack/register
>> space unnecessarily?
>
> How about when *using* the parameter. Effectively passing a reference to
> a pointer may not be the best way to get high performance.

It makes no real difference.  Any interaction with string_ref will be by 
calling member methods, which in turn require passing a pointer to the 
"this" instance (either on the stack or in register, depending on 
calling convention).  Either way, it's the same thing -- it either 
passes the reference it already has as a pointer or it passes the 
address of the local copy.  (Or more likely they'll be inlined.)

It might possibly inject one extra stack indirection if the reference is 
still in the stack rather than in a register, but that'll be in L1 cache 
(at least near function entry) and be pretty darn fast anyway.  If in 
doubt, profile it later.  Performance is a tricksy beast, especially 
once you go multi-core.

It's not that big a deal, though, in this case.  But const& is still the 
safest default parameter style, until you can prove that copies are 
cheaper than a stack indirection (or that moves are, and you can always 
move).  Don't even get me started on the people who think nothing of 
passing shared_ptrs around by value.