On 06/17/2016 04:01 PM, Gerald Squelart wrote:
On Friday, June 17, 2016 at 3:57:01 PM UTC+1, Gerald Squelart wrote:
On Friday, June 17, 2016 at 2:31:15 PM UTC+1, smaug wrote:
On 06/16/2016 06:40 PM, smaug wrote:
On 05/24/2016 08:33 AM, jw...@mozilla.com wrote:
For
RefPtr<T> GetFoo() {
RefPtr<T> foo;
// ...
}
should we:
1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)
Which one is preferred?
ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also
true for other compilers.
Can we somehow guarantee that RVO kicks in? It feels quite error prone to rely
on compiler optimization when dealing with
possibly slow Addref/Release calls.
https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support hints
that there are cases when RVO might not happen.
I've been told we can't guarantee RVO to kick in, which means, I think, that we
should assume we don't have RVO ever and need to
rely on other coding patterns which are guaranteed to optimize out extra
addref/release.
Currently having already_AddRefed as the return type is one such pattern.
What are the other options?
At least we can't start using RefPtr<T> as return type before we know it won't
be causing performance regressions.
So I would recommend using already_AddRefed for now.
From what *I* understand, RVO is guaranteed (or at least supported
everywhere?) when there is only one stack variable that is returned, e.g.:
C foo()
{
C rv;
// ... (put stuff in rv)
return rv;
}
In this case, the caller function stack can host 'rv' directly, no copies
needed.
RVO won't happen when there may be multiple variables in the function, only one
of which will be returned, e.g.:
C foo()
{
C rv1, rv2; bool b;
// ... (assign a value to b)
return b ? rv1 : rv2;
}
The caller cannot know which of rv1 or rv2 will be returned, so no return value
can be lifted.
(Any actual expert who knows the truth?)
(sorry for the spam)
If I'm correct, then the question becomes: Can we trust developers to always
make the right choice?
No. And reviewers won't catch it either.
Or better: Can we write static analyzers that will catch RVO-hostile code?
So this is the question.
And what then when the code is RVO hostile? developer is forced to write possibly uglier but non-RVO-hostile code? I could live with that I guess,
hoping that it happens rarely.
-Olli
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
