Re: [boost] [function] function wrapping with no exceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with no exceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-30 15:07:42

On Fri, Oct 29, 2010 at 4:45 PM, Nevin Liber <nevin_at_[hidden]> wrote:
> On 29 October 2010 15:02, Daniel Walker <daniel.j.walker_at_[hidden]> wrote:
>> Result (Debug): Defining BOOST_FUNCTION_USE_STATIC_EMPTY yields a 18%
>> decrease in time overhead per call but doubles the space overhead per
>> type.
>
> Does it?  Presumably in the non-static-empty case the NULL pointer
> check and throw are getting inlined, resulting in more code space
> overhead the more times a given type is reused (which is typical, at
> least in my experience)?  Projects low on static space tend to be low
> on code space as well.  One would expect the code savings overhead to
> be amortized fairly quickly.

Well, we can answer these questions empirically using the benchmark
executables (see the Trac ticket for source code). On my system, the
text section of the text segment grows from 3728B to 4608B when the
static empty scheme is used. The reason that the static empty scheme
increases the code size is that it increases the number of
boost::function internal class and function templates instantiated in
order to handle the "empty" function in addition to the actual target
function.

>
>> So, I think the current boost::function implementation is certainly
>> the right default, since many users would not appreciate doubling the
>> static space overhead for a time savings of less than 10% per call.
>
> Is it?  Projects low on static space usually don't have cycles to burn, either.

I think users should have the opportunity to tinker and discover which
scheme works best for their project. However, the current behavior
seems like a good default. Remember, the benefit of the static empty
scheme is dependent on the compiler optimization, the call context,
etc. Depending on the user's situation, the new scheme could have no
discernible benefit at all. However, in all situations the static
empty scheme has a cost.

Also, remember, we're talking about a difference of %4 of a call to
boost::function, not 4% of the call to the actual target function. If
the target function is very cheap, then boost::function overhead could
matter. But the more cycles the target function consumes, the less
significant the overhead of boost function. The applications that
would benefit most from the static empty scheme are those that spend a
significant portion of their cycles calling boost::function rather
than doing actual work. I think it's safe to assume that this is not
the norm. So, why force most users to increase their static space
overhead for nothing?

Daniel Walker