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
> The run-time lookup is only within connections of the same type. So,
> 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
> is necessary because of the non-intrusive nature of Synapse: any object of
> whatsoever can be used as an emitter.
I have designed systems with 10s of thousands of observable components being
by thousands of other objects, which in turn may end up triggering events to
other objects. As such, allowing the instance to emit the signal to be
for a dependency driven update. Depending on the situation, this could
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
I would trigger an 'update pending' call that would bundle the updates...
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
> without a practical use case. In my experience the connected user function
> user code that is executed within emit<>(pe) for each connection to the
> emitter 'pe') is usually significantly heavier than the Synapse machinery.
Stock portfolios are a good test of data driven performance. There are tens
of observable objects (stocks) being observed by potentially thousands of
triggered, the update would need to update a value roll up of the portfolios
Once wired, the system should be able to push at least 2000 stock updates
Using the subject/observer patterns as I've implemented them allows for
driven updates and a fairly small memory overhead. It also allows for
to hook into the notification without much of a hassle.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk