Re: [boost] first steps to submitting - boost :: observers

Subject: Re: [boost] first steps to submitting - boost :: observers
From: Robert McInnis (r_mcinnis_at_[hidden])
Date: 2016-09-19 02:36:31

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.

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 is a priority for me, however it is pointless to discuss
performance 
> 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
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.