performance test between boost::signals and sigc++-2.0
Dear Boosters I am using quite intensively boost::signals but I noticed a relatively high cost. I wrote a small test program that confirmed it with a comparison to sigc++-2.0. The code has been compiled with g++-3.3 -O3 and this is a very recent boost cvs snapshot(compiled in release mode). It was run on a Debian(sid)/GNU/Linux ibm thinkpad T40p (pentium M) I vary the number of slots (0 to 4) and calls and I have a dummy slot class and a less dummy slot class to test with. here are the timings: ================================================================== call dummy::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0 0 nan 0 10000 0 0 nan 0 100000 0.05 0 inf 0 1000000 0.5 0.01 50 0 10000000 4.95 0.11 45 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.01 0.01 1 1 100000 0.1 0.02 5 1 1000000 1.08 0.14 7.71429 1 10000000 10.55 1.34 7.87313 2 100 0 0 nan 2 1000 0 0 nan 2 10000 0.02 0 inf 2 100000 0.14 0.02 7 2 1000000 1.45 0.14 10.3571 2 10000000 14.6 1.46 10 3 100 0 0 nan 3 1000 0 0 nan 3 10000 0.02 0 inf 3 100000 0.19 0.01 19 3 1000000 1.84 0.15 12.2667 3 10000000 18.44 1.53 12.0523 ================================================================== call A::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0.01 0 inf 0 10000 0 0 nan 0 100000 0.05 0 inf 0 1000000 0.48 0.01 48 0 10000000 4.87 0.11 44.2727 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.02 0 inf 1 100000 0.12 0.01 12 1 1000000 1.15 0.22 5.22727 1 10000000 11.46 2.17 5.28111 2 100 0 0 nan 2 1000 0.01 0 inf 2 10000 0.01 0.01 1 2 100000 0.16 0.03 5.33333 2 1000000 1.61 0.32 5.03125 2 10000000 16.17 3.14 5.14968 3 100 0.01 0 inf 3 1000 0 0 nan 3 10000 0.02 0 inf 3 100000 0.21 0.04 5.25 3 1000000 2.09 0.41 5.09756 3 10000000 20.83 4.06 5.13054 Am I using boost::signals the wrong way? has boost::signals some added features that reduce its performance ? I apologize in advance if it has already been discussed before but I didnot find a relevant discussion in the archives or on google. I found some feature comparison here http://www.3sinc.com/opensource/boost.bind-vs-sigc2.html For my application the number of calls are typically between 1e6 and 1e8 with a few slots (1 to 10 ). The cost of boost::signals framework is quite high. Best regards C. -- Christophe Prud'homme Office MA B2 534 CMCS-IACS EPFL CH-1015 Lausanne, Switzerland Tel: +41 (0)21 693 25 47 Fax: +41 (0)21 693 43 03
Douglas Gregor wrote:
On Jun 18, 2005, at 9:43 AM, Christophe Prud'homme wrote:
Am I using boost::signals the wrong way? has boost::signals some added features that reduce its performance ?
The latter. The "slot groups" feature really slows Signals down.
As I understand it, you were going to remove it. Is that still in the plans ? I like the "slot groups" feature as it enables one to order signal handlers if necessary. This is sometimes both necessary and easy to do with slot groups when designing code using signals where one wants to guarantee that internal handlers be called before any user-defined handlers. But since it is slowing down Signals significantly, I think it should either remain run-time optional in some way where its non-usage would not slow down Signals, or removed. In this scenario, which I do not know it is possible for you to do, only those who use the slot mechanism would pay the higher price in slower calling of signal handlers. I do not know the Signals code but, as a suggestion, how about the ability to pass a bool to the signal constructor itself, defaulting to 'false', which determines whether or not slot groups are supported. If slot groups are not supported for a signal, then if a slot group is passed to a connect call the group is ignored and the slots are handled strictly with the FIFO. At the cost of some changes in code design would that not essentially save time by not having to cycle through the slot groups in order to call slots when the signal is triggered ? FIFO satisfies most people's needs and despite the fact that I had previously suggested a much more flexible usage in the past which you had largely adopted for signals, my opinion is that it is very important that signal handling speed compare reasonably to other systems, especially as signals may be used heavily for front-end GUI programming.
Christophe, thanks for the benchmarking program! I'm in the process of removing the boost::any usage in signals. Right now I've moved everything into a header file. My numbers look a bit better. razeh@squirmy:~/boost-signals$ ./tbs-snapshot 4 10000000 ================================================================== call dummy::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0 0 nan 0 10000 0.01 0 inf 0 100000 0.07 0.01 7 0 1000000 0.75 0.03 25 0 10000000 7.61 0.31 24.5484 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.02 0 inf 1 100000 0.13 0.04 3.25 1 1000000 1.32 0.39 3.38462 1 10000000 13.28 3.66 3.62842 2 100 0 0 nan 2 1000 0.01 0 inf 2 10000 0.02 0 inf 2 100000 0.19 0.04 4.75 2 1000000 1.9 0.4 4.75 2 10000000 18.92 3.88 4.87629 3 100 0 0 nan 3 1000 0.01 0 inf 3 10000 0.02 0.01 2 3 100000 0.24 0.05 4.8 3 1000000 2.39 0.43 5.55814 3 10000000 23.83 4.14 5.75604 ================================================================== call A::operator() #Slots #Calls boost::signals sigc++-2.0 Ratio 0 100 0 0 nan 0 1000 0 0 nan 0 10000 0.01 0 inf 0 100000 0.07 0.01 7 0 1000000 0.76 0.03 25.3333 0 10000000 7.68 0.33 23.2727 1 100 0 0 nan 1 1000 0 0 nan 1 10000 0.02 0 inf 1 100000 0.16 0.06 2.66667 1 1000000 1.62 0.6 2.7 1 10000000 15.93 6.06 2.62871 2 100 0 0 nan 2 1000 0 0 nan 2 10000 0.03 0.01 3 2 100000 0.25 0.09 2.77778 2 1000000 2.43 0.84 2.89286 2 10000000 24.32 8.43 2.88493 3 100 0 0.01 0 3 1000 0 0 nan 3 10000 0.03 0.01 3 3 100000 0.31 0.12 2.58333 3 1000000 3.21 1.08 2.97222 3 10000000 31.93 10.95 2.91598 razeh@squirmy:~/boost-signals$ uname -a Linux squirmy 2.6.8-2-k7 #1 Thu May 19 18:03:29 JST 2005 i686 GNU/Linux razeh@squirmy:~/boost-signals$ gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-13) I've attached a patch --- but I haven't done much testing with it, and it represents something I'm in the middle of.
participants (1)
-
Christophe Prud'homme -
Douglas Gregor -
Edward Diener -
razeh