You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing mechanism was a great proof of concept, but it is probably not the most performant solution (esp. when there are many monsters and many events).
The ideal solution probably has to cache the previous state and diff it against the current state to only send updates (inserts, updates, deletes). I have not found a suitable generic data structure diff library, so I'll have to handroll this for now.
I suspect this will be easier with #85 (which should be a huge performance win, too), so for now this depends on that.
The text was updated successfully, but these errors were encountered:
Well, sexp-diff can do some of the work, but I think it does not recur into structure-types (nor, presumably, observables). It's also not exactly clear how to use that here.
Another possibility is as follows: if the problem is over-subscribed observables, why not reverse the protocol? The GUI can emit events that any program can subscribe to and handle. This forces the GUI code to decide what events to emit and at what (presumably logical) points. The undo functionality would also be a client of this system.
The mechanism could either be a logger or a multicast channel, as long as it's async & fire-and-forget (both are).
There's still a question of what to when consuming events (pass the state along?) and what the "initial" state for a request should be (same as current?).
The existing mechanism was a great proof of concept, but it is probably not the most performant solution (esp. when there are many monsters and many events).
The ideal solution probably has to cache the previous state and diff it against the current state to only send updates (inserts, updates, deletes). I have not found a suitable generic data structure diff library, so I'll have to handroll this for now.
I suspect this will be easier with #85 (which should be a huge performance win, too), so for now this depends on that.
The text was updated successfully, but these errors were encountered: