Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-11-07 15:54:14

On Sat, Nov 6, 2010 at 5:31 PM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> On 11/6/2010 10:22 AM, Daniel Walker wrote:
>>
>> On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr.
>> <jhellrung_at_[hidden]>  wrote:
>>>
>>> On 11/02/2010 02:50 PM, Daniel Walker wrote:
>>> [...]
>>>>
>>>> Here are the results I got, again, using the build of g++ 4.2 provided
>>>> by my manufacturer.
>>>>
>>>> Data (Release):
>>>>            |  function   | function (static empty)
>>>> time/call  |  3.54e-07s  |  3.51e-07s
>>>> space/type |    64B      |    80B
>>>>
>>>> Data (Debug):
>>>>            |  function   | function (static empty)
>>>> time/call  |  2.05e-06s  |  2.04e-06s
>>>> space/type |    64B      |    80B
>>>>
>>>> You can see that removing the empty check from boost::function yields
>>>> about a 1% improvement in time per call to boost::signal. The
>>>> increased space per type overhead is the same as before: 16B.
>>>
>>> [...]
>>>
>>> [Butting in after only vaguely following this thread...]
>>>
>>> Would it also be appropriate to measure the "space/call", in addition to
>>> "time/call" and "space/type"?  Or is there no difference, or had this
>>> been
>>> addressed already?
>>
>> Well, a call to boost::function does not cost any additional space.
>
> I'm not sure what you mean.  "Additional" to what?

In addition to not calling boost::function.

All of the additional space overhead is incurred when boost::function
is instantiated (and assigned). No additional space overhead is
incurred when an instantiated object is called at runtime, though of
course the call does take up space for code in the text segment.

>
> Isn't the underlying dispatching code different for the 2 implementations of
> boost::function you're comparing above?  I.e., one has a null-pointer check,
> while the other doesn't.  One might hypothesize that the dispatching code
> that must perform a null-pointer check will compile to more instructions
> than the dispatching code that does not perform a null-pointer check, and I
> presume the timings above support this hypothesis.  I would think this
> should lead to variations in the size of the code segment.  This variation
> might be more pronounced if the dispatching were inlined.  I'm just
> speculating...

Yes, the text segment size also changes. And in fact, I believe, we
could move the space overhead in the data segment to the text segment
by making the static initialized vtable constant, as was suggested
earlier in this thread. So, the text segment size could be more
important in determining the expense of the static empty scheme.

Daniel Walker