7

In an environment restricted to C++03,boost::signals2 was used alongside boost::function and boost::bind to implement a simple messaging system between components. It works great and I have no problems with it whatsoever.

However, in another environment where C++11 is supported fully, is boost::signals2 overkill for very simple applications?

To clarify, by simple I mean the following:

  • Single threaded
  • All signals have the return type void

Performance is key in this application, so all the wonders of boost::signals2 that the application doesn't need could be doing more harm than good.

Right now, there is simply an std::vector<std::function> handling this, and switching over to something else such as boost::signals2 would be very simple to do if it was deemed suitable.

OMGtechy
  • 7,935
  • 8
  • 48
  • 83
  • so what did your profiler tell you about the amount of CPU/memory usage from `Boost.Signals2`? is it even a bottleneck? – TemplateRex Mar 14 '14 at 23:17
  • 3
    If performance is key, I usually find myself **not** implementing subscribable events or observables. That's invariably a separate layer from the processing. – sehe Mar 14 '14 at 23:18
  • @sehe but you could have observers of a high-performance computation, at some point they will have to be notified, it's up to the app to tune the update frequency depending on performance needs – TemplateRex Mar 14 '14 at 23:19
  • It's not a problem *yet*, but since I plan on rewriting that part of the application I thought I may was well draw on peoples better knowledge and *avoid* performance problems in the future now instead of needing yet another rewrite when it becomes a problem. I'm also just curious! – OMGtechy Mar 14 '14 at 23:23
  • 1
    As Andrei Alexandrescu said... `The only good intuition: "I should time this."` Three Optimization Tips for C++ http://www.slideshare.net/andreialexandrescu1/three-optimization-tips-for-c-15708507 – amdn Mar 14 '14 at 23:30
  • @amdn Thanks for the link, I'm looking at it now. – OMGtechy Mar 14 '14 at 23:37
  • He knows a thing or two about high performance C++ http://en.wikipedia.org/wiki/Andrei_Alexandrescu, the point of the link is you can't go wrong measuring... lots of intuition is simply wrong when it comes to performance. – amdn Mar 14 '14 at 23:44
  • @TemplateRex precisely. That's why I'd prefer lockless containers/atomics to share the stats and indeed make the frequency completely transparent – sehe Mar 14 '14 at 23:57
  • 7
    It seems that this question has boiled down to, **stop theorizing, start benchmarking**. Thank you for your help. – OMGtechy Mar 15 '14 at 00:05
  • Unrelated to the performance discussion, note that `Boost.Signals2` [definitely have advantages](http://stackoverflow.com/questions/18663490/how-and-why-one-would-use-boost-signals2/18681348#18681348) over `vector`. – Igor R. Mar 16 '14 at 08:04
  • 1
    @IgorR. thank you, after reading that and a few other things I went with boost::signals2 in the end :) – OMGtechy Mar 17 '14 at 20:21

2 Answers2

20

I recently came across the same question for a project with similar simple requirements and did some research that I'd like to share here.

My main interest was in the overhead of boost::signals2 compared to a simple vector-of-callback-functions implementation. Finally I did some more research as shown in the following table:

    Benchmark                                       Duration (normalized)
    ---------------------------------------------------------------------
    Direct function call                            1
    Function pointer call                           1
    Virtual function call                           1
    std::function call                              1.5
    std::vector<std::function> call                 2
    boost::signals signal invocation                78
    boost::signals2 signal invocation (dummy mutex) 43
    boost::signals2 signal invocation               92

The measurements have been taken on a Ubuntu 15.04 with gcc 4.9.2, optimization -O2, Boost v1.55. Because the absolute values might well be meaningless outside of my box the values are normalized. More recent versions of Boost might well be faster.

My conclusion would be: If performance is critical and you don't need thread safety (or other advanced features) reconsider using boost::signals2.

If you want to reproduce the measures on your machine the code is available here.

Florian
  • 1,036
  • 10
  • 15
3

To conclude the conversation had in the comments:

It seems that this question has boiled down to, stop theorizing, start benchmarking

In the end, I found the some of the additional features of boost::signals2 were highly beneficial (such as .track on slots) and worth any performance cost, if any, they incurred.

OMGtechy
  • 7,935
  • 8
  • 48
  • 83