Re: [boost] [function] function wrappingwithnoexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrappingwithnoexceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-11-15 13:15:01

On Sat, Nov 13, 2010 at 2:45 PM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote> On 11/13/2010 10:39 AM, Daniel Walker
wrote:
>>
>> On Mon, Nov 8, 2010 at 7:24 PM, Domagoj Saric<dsaritz_at_[hidden]>  wrote:
>>>
>>> "Daniel Walker"<daniel.j.walker_at_[hidden]>  wrote in message
>>> news:AANLkTin+bj=YeGtpo7sqLMUq2Nx3uG_teEFbcDMsM5Eb_at_mail.gmail.com...
>>>>
>>>> On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr.
>>>> <jhellrung_at_[hidden]>  wrote:
>>>>>
>>>>> 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.
>>>
>>> How (or better, why) can you possibly claim something as plainly false as
>>> this..?
>>>
>>> That this is false is obvious to anyone just following the discussion
>>> (and
>>> all the talk about the redundant if empty then throw logic/code) not to
>>> mention to someone that actually poked around the source code or even
>>> looked
>>> at the generated code....
>>
>> boost::function allocates space when it is instantiated and assigned
>> (e.g. line 580 of function_template.hpp), but not during a call to
>> boost::function. Perhaps, you are referring to stack allocation? Yes,
>> a call to boost::function could result in the stack growing, but that
>> wasn't the question. If you are referring to the memory in the text
>> section of the executable used to define operator() itself, yes,
>> that's obvious, this is another space expense per type, but that
>> wasn't the question. If you are aware of some other memory which is
>> consumed during a call to boost::function, could you please be
>> specific and include line numbers?
>
> Actually, my original question was regarding space/call, with "space"
> referring to the same thing as your "space/type", i.e., space in the
> executable (in this case, the text segment).  I believe I clarified this in
> a later post (no link handy).  Sorry, I thought the context of the question
> made the terminology unambiguous.

OK, thanks for the clarification. The space per type in the text
segment is now the only space overhead of the static empty scheme,
since the static vtable assignment can be made const. So the size in
the text segment is now the only important question. :) I re-ran the
two benchmarks attached to the Trac ticket using gcc 4.2 and report
the results below including text segment size.

Function Benchmark Data (Release):
                   | current   | static empty
time/call          | 6.69e-09s | 6.26e-09s
space/obj          |   32B     |   32B
space/type (data)* |   32B     |   32B
space/type (text)  |  6347B    |  7386B

Signal Benchmark Data (Release):
                   | current   | static empty
time/call**        | 1.55e-07s | 1.57e-07s
space/obj          |   N/A     |   N/A
space/type (data)* |   32B     |   32B
space/type (text)  |  46539B   |  47361B

* Total size of the initialized static data section of the data
segment, which shows that boost::function's contribution is 0B.

** On my machine these times are not consistent with every run.
Sometimes the static empty scheme is up to 9% faster.

So, you can see that the static empty scheme may or may not yield some
time savings, but it does increase the total size of the text section
by around 1000B in both tests. Again all of this is highly dependent
on the compiler optimization and the specific circumstance in which it
is used, which is why users should be given the choice as to whether
or not to enable the static empty scheme.

Daniel Walker