lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Is it unhelpful to move containers explicitly?


From: Greg Chicares
Subject: Re: [lmi] Is it unhelpful to move containers explicitly?
Date: Thu, 11 Oct 2018 00:26:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 10/7/18 5:43 PM, Vadim Zeitlin wrote:
> On Sun, 7 Oct 2018 15:24:50 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> As an experiment, I changed make_evaluator() to pass vector
> GC> parameters as const& instead of &&, and the measured speed did
> GC> not discernibly change. Perhaps the operation of passing these
> GC> parameters is just a negligible portion of the work done by
> GC> make_evaluator(),
> 
>  Yes, I'm pretty sure this is the case. This vector doesn't have that many
> elements and it's copied only once, AFAICS, so it's not going to take any
> significant time on its own.
> 
> GC> but even in that case wouldn't it be better to simplify the code by not
> GC> writing std::move()?
> 
>  I don't think so. This would be a premature pessimization, similar to
> passing a vector by value instead of const reference when you don't need to
> copy it.

Okay. I wouldn't normally pass a vector by value when const& is better.
Yet const& is by now an ingrained habit; and even in the 1990s it was a
simple enough to learn easily. Maybe moving will seem simple in
retrospect, in some later decade; it just seems tricky to me right now.

> GC>   
> https://isocpp.org/blog/2013/02/no-really-moving-a-return-value-is-easy-stackoverflow
> GC> | often the cleanest, simplest code that doesn't even mention
> GC> | move or && anywhere is just what you want
> 
>  Sorry, but this was said in a completely different context. The question
> above is about _returning_ objects from functions, not passing them into
> them and there is no implicit optimization (even in practice, let alone
> guaranteed by the standard) similar to RVO that applies in the latter case.

I was looking for a way to avoid studying move semantics, because...
 - it's just one more thing to learn, but our time is finite, and
 - lmi does explicit moves only in rare cases where the benefit is slight.
But the reason why we've so seldom written explicit moves is that we're
generally passing data as return values, where RVO applies.

Yet making RVO apply here would require combining the vectors and scalars
into a single object, e.g.

  ledger_evaluator::ledger_evaluator(Ledger const& ledger)
    :vectors_and_scalars {ledger.format_the_vectors_and_scalars()}

which is against nature: we're better off writing std::move().

[...snip your patch that does exactly that, which I've applied...]

>  I'd be somewhat curious if this makes any noticeable difference but even

It seems to have no discernible effect on run time in the unit test.

> if it doesn't, I think this patch should still be applied instead of the
> original one because it does make sense to move the maps into the evaluator
> here: it takes ownership of them, if you'd like.

Everyone agrees that 'std::move()' is a misleading name. In one online
discussion that I came across, someone suggested that 'std::plunder()'
would be better; it makes sense if you've watched enough pirate movies.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]