On Fri, Oct 29, 2010 at 4:45 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 29 October 2010 15:02, Daniel Walker <daniel.j.walker@gmail.com> 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