On Mon, Nov 8, 2010 at 7:19 PM, Domagoj Saric <dsaritz@gmail.com> wrote:
"Daniel Walker" <daniel.j.walker@gmail.com> wrote in message news:AANLkTinT6ofcXAi3TsBCDoDqLVgLn-sK4g0pV9pPOGu7@mail.gmail.com...
On Sat, Oct 30, 2010 at 1:25 PM, Domagoj Saric <dsaritz@gmail.com> 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