On Monday, September 19, 2016 1:16 AM Emil Dotchevski said:
In Synapse signals are types, the dispatch by signal is done at compile time. The run-time lookup is only within connections of the same type. So, emit<S>(pe), where S is a signal type and 'pe' is a raw pointer, searches only within S
connections for a connection to an emitter with address equal to 'pe'. The lookup is necessary because of the non-intrusive nature of Synapse: any object of any type whatsoever can be used as an emitter.
Performance is a priority for me, however it is pointless to discuss
without a practical use case. In my experience the connected user function (the user code that is executed within emit<>(pe) for each connection to the
I have designed systems with 10s of thousands of observable components being observed by thousands of other objects, which in turn may end up triggering events to alert other objects. As such, allowing the instance to emit the signal to be observed allows for a dependency driven update. Depending on the situation, this could radically cut down on the number of object instances that would need to be notified. In some cases, where a displayed item is updated very often (more than 50 updates/sec), I would trigger an 'update pending' call that would bundle the updates... thereby reducing The UI updates to whatever I wish (many times less than 20 updates/sec) performance passed
emitter 'pe') is usually significantly heavier than the Synapse machinery.
Stock portfolios are a good test of data driven performance. There are tens of thousands of observable objects (stocks) being observed by potentially thousands of objects. Once triggered, the update would need to update a value roll up of the portfolios updated worth. Once wired, the system should be able to push at least 2000 stock updates per second. Using the subject/observer patterns as I've implemented them allows for dependency driven updates and a fairly small memory overhead. It also allows for unrelated observers to hook into the notification without much of a hassle.