Re: [boost] [function] function wrappingwithnoexceptionsafetyguarantee

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

On Mon, Nov 8, 2010 at 7:19 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>
> "Daniel Walker" <daniel.j.walker_at_[hidden]> wrote in message
> news:AANLkTinT6ofcXAi3TsBCDoDqLVgLn-sK4g0pV9pPOGu7_at_mail.gmail.com...
>
>> On Sat, Oct 30, 2010 at 1:25 PM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>>>
>>> e.g. http://lists.boost.org/Archives/boost/2010/01/160908.php
>>
>> Thanks. I added a tarball, signal_benchmark.tar.bz2, with a jamfile
>> and source code so that anyone who's interested can easily reproduce
>> this benchmark. The benchmark measures the impact of the static empty
>> scheme on the time per call of boost::signals2::signal using the code
>> Domagoj linked to. Thanks to Christophe Prud'homme for the original
>> benchmark!
>>
>> 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.
>
> You just missed one important detail mentioned in the original post which is
> to use a dummy mutex...

I simply ran the code you linked to.

> <snip>
> The patch provided switches to a dummy mutex, adds two zeros to N, adjusts
> the benchmark's priority, corrects the number-of-calls calculation and skips
> the invocation of empty signals...

OK, I applied your patch, and I uploaded a new tar ball to ticket 4803
incorporating your changes. Here are the new timing results on my
system's gcc 4.2 in release mode.

Data (Release):
          |  function   | function (static empty)
time/call  |  1.73e-07s |  1.57e-07s

So, in this case, you can see that the static empty scheme yields
about a 9% improvement in the average time of the test function
(normalized by the number of slots and calls). So, again, this shows
that it is possible that some users could experience some benefit from
the static empty scheme, and we should allow them the opportunity to
experiment, determine what works best for their project and choose the
appropriate configuration option.

Daniel Walker