turt2live
commented
3 years ago A slightly better drawing (click to zoom):
The overarching theory is that we can get better performance by waking up less things. As such, we can integrate the ViewModel concept into the dispatcher system as well, reducing the chance that the component will be woken up for an arbitrary dispatch. We don't necessarily want to wake all the models either though, as this could result in a lot of state dedupe checks: this is why there's multiple layers of dispatcher above it.
In the diagram, we've created a number of "feeds" that a model can listen for, which can then inform the components about updates. Anything the components want to dispatch would get dispatched back to the model [dispatcher] which then dutifully sends it off the central dispatcher. The feeds help avoid waking the models too much by allowing the models to subscribe to mildly more interesting information than "all of the Room stuff". In practice, this feeder layer might have near-zero effect on performance, but might help with developer happiness in knowing that they are not having to repeat the if (payload.roomId !== this.roomId) return; checks over and over.
The feeders are expected to filter coarse topics down to something that models might be interested in, such as per-room streams and splitting the crypto stream in two (or combining two coarse streams into a filtered User topic, such as combining user trust changes with user presence). The coarse dispatchers are largely responsible for picking off major topics from the central dispatcher: the diagram above has the likely 6 we'd have. We wouldn't really end up with many more.
Where a coarse topic might not need any filtering (ie: the UI topic), a passthrough feeder would be created to avoid breaking the semantics of models being fed data from a "filtered" perspective.
In a multiaccount world, we could end up with something like this:
The global dispatcher would be a broker between the various CentralDispatchers which represent 1 account each. The lines between the central and global dispatchers are smaller because the central dispatchers would know what sort of cross-account information is interesting, and the global dispatcher would likely re-fire it to all the other central dispatchers it knows about.
The names "central" and "global" would probably need renaming in these scenarios, given central is obviously not central anymore. Possibly just "global" and "client".
As mentioned, these layers might be overkill for reducing wake counts, but might help with more fluid development. I'm interested in people's thoughts though, given this is a pretty major change (and one that affects pretty much all future development).
kegsay
Working theory:
(not to scale)
We can likely improve app performance by simply waking up less components with the global dispatcher. The diagram above is one possible solution, where there are core dispatchers (to avoid waking each other up with noise) and "feeder" dispatchers which are relevant to a particular entity (room, user, model, etc). Those feeder dispatchers would subscribe to specific details from the more coarse dispatchers and filter down accordingly, then filter down again before activating downstream listeners.
As a performance baseline, this is what a random snapshot of activity on my main account (develop, chrome) looks like:
The first few spikes are room switches (with Spaces enabled), then we move into sending messages, browsing rooms, and handling stress tests in megolm-test.
The metrics to beat are (if we assume that the performance issues are in fact because of the dispatcher):