Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-01-30 15:49:36

From: Dave Abrahams
>> I don't personally think that the style of programming that optional
>> is intended for is suitable for high performance/performance critical
>> situations in the first place.  

>Why not?  It seems like a great candidate for common compiler
>optimizations.

To some extent it depends what style of programming optional is intended for.  What I had in mind was the highly object oriented defensive programming style that emphasizes safety often at the expense of performance in vogue around the time Java came out.

>> Pass by reference and return a bool for a conditional return value.
>> Pass the bool and the object separately for a conditional argument.
>> Pass or return a pointer and check if it is null.  Yes, my advice
>> really is to not use optional if you want performance.  

>Why?

I like pass by reference and return a bool over returning an optional for performance because we allocate memory for the result of the function outside of the function call and there is no transfer of ownership of the result.  Even with move semantics, you have just changed an unnecessary copy into cheaper unnecessary move.

>> Even if we did everything you can think of to make optional fast you
>> are still better off designing your interfaces in such a way that you
>> don't need it if your goal is performance.  

>Why do you say that?

I don't trust the compiler to always inline what I want it to if it is busy inlining the optional function calls.  The compiler heuristics for inlining can get overloaded and confused as the number of nested inline functions grows.  There are no inline function calls to check the bool return value of a function or use the reference passed to the function.  I believe that getting the ownership of the data at the right place in the code for performance is preferable to transferring ownership, even with move.  It also helps the compiler optimize to be given less code that looks more like what you want the compiler to produce at the end so that it has less opportunity to fail to give you what you wanted.  We can imagine an arbitrarily good compiler that always does what we intend, but a compiler that generates a branch for "if(m_initialize) m_initialize = false" is clearly not the ideal compiler we imagine.

I did come around to supporting optimization of optional, it might as well be as good of a trade off between safety and performance as we can make it.  I don't use optional myself because I prefer alternative syntax for simplicity reasons, convenience, fewer dependencies, etc, and not even performance reasons.

Regards,
Luke