[Signals2] Signal memory overhead
Hello, I've been using the Signals2 library for a while now, and I'm very happy with it. But lately I have noticed that the library seems to have a rather large overhead in terms of memory consumption. My measurements indicate 233 bytes per signal<>, and an additional 128 bytes of overhead per connected slot. Connections themselves are lightweight at 24 bytes, as expected. I've been measuring on Linux 64bit, by creating a class with one signal and a number of active connections to that signal. This class is instantiated on the heap and the pointer is discarded. When run under Valgrind, I get the numbers mentioned above. All measurements have been done with threading support disabled (using boost::signals2::dummy_mutex). Since I don't need most of the features (my signals have one active connection most of time, seldomly more), I hacked together a small replacement that fits my needs as well. That code measures at 32 bytes per signal, 32 bytes per slot and 16 bytes per connection. Of course it provides nothing except connect/disconnect and operator(). Am I using the library incorrectly? Does my measurement method skew results? -- Sean
Since I don't need most of the features (my signals have one active connection most of time, seldomly more), I hacked together a small replacement that fits my needs as well. That code measures at 32 bytes per signal, 32 bytes per slot and 16 bytes per connection. Of course it provides nothing except connect/disconnect and operator().
Am I using the library incorrectly? Does my measurement method skew results?
Do you mean that it's possible to lower signals memory consumption in a general use-case as well?
Do you mean that it's possible to lower signals memory consumption in a general use-case as well?
I don't know. I haven't looked into the implementation of Signals2 yet, but at least for applications that require only singlethreaded connect, disconnect, and dispatch the overhead can be lowered somewhat. Always provided that I haven't made any big mistakes.
On 20.03.2012 19:20, Sean Buckheister wrote:
Do you mean that it's possible to lower signals memory consumption in a general use-case as well?
I don't know. I haven't looked into the implementation of Signals2 yet, but at least for applications that require only singlethreaded connect, disconnect, and dispatch the overhead can be lowered somewhat. Always provided that I haven't made any big mistakes.
I'm not sure, but I always thought signals1 was without any synchronization and signals2 was added especially because of the synchronization it does. So if that is the case, you might as well use Signals1 instead of 2, if you don't need any synchronization and are concerned about the overhead. Or did I get that wrong? I'm not a regular user of any Signals library and just read the documentation some time ago, so I'm really not sure. Norbert
I'm not sure, but I always thought signals1 was without any synchronization and signals2 was added especially because of the synchronization it does.
So if that is the case, you might as well use Signals1 instead of 2, if you don't need any synchronization and are concerned about the overhead.
Or did I get that wrong? I'm not a regular user of any Signals library and just read the documentation some time ago, so I'm really not sure.
Signals2 has one more advantage: it allows tracking slots by weak_ptr.
On 21.03.2012 10:36, Igor R wrote:
I'm not sure, but I always thought signals1 was without any synchronization and signals2 was added especially because of the synchronization it does.
So if that is the case, you might as well use Signals1 instead of 2, if you don't need any synchronization and are concerned about the overhead.
Or did I get that wrong? I'm not a regular user of any Signals library and just read the documentation some time ago, so I'm really not sure.
Signals2 has one more advantage: it allows tracking slots by weak_ptr.
Thanks for the clarification. Norbert
To illustrate my point, and what my (idea of) a very simple signals impl can do, I've attached some cleaned up code. The overhead is pretty low already, and some concurrency and combinator functionality as in Signals2 could be implemented without too high a cost. Also, if one were to supply a wrapper for object methods that is not boost::bind nested in boost::function, even more could be saved.
participants (3)
-
Igor R -
Norbert Wenzel -
Sean Buckheister