Batching frequent updates

[jslew]

Hello,
We have some features that pull their data via http and then subscribe to "real-time" updates via a websocket. In certain circumstances, the updates cause ui lag (particularly when scrolling) and we have a rather complicated system of batching updates and applying them all at once at 1-second intervals or whenever scrolling ceases, whichever is later. I'm wondering whether it might be possible to attack this from the other side, allowing changes to flow into the store as they arrive but preventing them from triggering SwiftUI updates until scrolling is complete. It seems like it might be simpler to implement this way, but I don't know if a mechanism like that exists. I almost want a "shadow store" which operates on a copy of the state and then overwrites the real state all at once. Any ideas welcome!

[kamcma]

I'd start by reviewing the docs page on performance, particularly the section on high-frequency actions, if you haven't seen it already. You are right to be cautious about sending high-frequency updates to the store.

I've not used any of these myself, but I think there are a few ways to handle this.

Effect.throttle and Effect.debounce were re-introduced in 1.1.0:

private Enum CancelID { case highFrequencySubscription }

//

return .run { send in
  // setting up high-volume subscription
  for await value in self.fooClient.highFrequencyAsyncStream() {
    await send(.receivedFoo(value))
  }
}
  .throttle(id: .highFrequencySubscription, for: .seconds(1), scheduler: self.mainQueue, latest: false)

Alternatively, I think you could handle this at the concurrency level with Apple's async-algorithms package. (I'm not personally super familiar with this API but it's the same idea):

import AsyncAlgorithms

//

return .run { send in
  for await value in self.fooClient.highFrequencyAsyncStream().throttle(for: /* ??? */, clock: /* ??? */, latest: false) {
    await send(.receivedFoo(value))
  }
}

If your high-frequency dependency is already a publisher instead of an AsyncStream, you could just use it and any Combine operators directly:

return .publisher {
  self.fooClient.highFrequencyPublisher()
    .throttle(/* ... */)
    // and any other Combine operators you want
}

The nice thing about doing it this way, in the reducer, is the dependency can remain totally agnostic how frequently its caller is able to take updates.

[jslew]

Thanks, I'm aware of both the performance article and the throttle operators. Unfortunately, 'throttle' is not semantically correct since I want to accumulate all the updates so I can apply them as one big update at the end of a predefined period (not pause between each update.). It really seems in my case that it is the SwiftUI side of things getting bogged down, not the reducer, per se. My current approach is to accumulate the updates in State "off to the side" (i.e. not within the scope of the view's state), and then when the throttle timer fires or scrolling stops, apply the accumulated updates to the view-scoped state in one go. Like I said, this works fine so I don't think it's the machinery of the Store which is the problem so much as triggering too many view recalcs within a short period of time. But it's complexity that I need to replicate for many similar features so I am looking for a way to simplify or factor out that part of it.

[kamcma]

Even if you want to accumulate emissions from some high-frequency subscription into a batch, don't then map that whole collection of emissions one-to-one into actions sent back into the store. Either pre-reduce those emissions into a single value in the dependency, or have a single action that takes a collection of the emissions (case receivedBatch([Emission])) and do whatever logic in the reducer. Either way, only send one action per batch, not one action per emission per batch. SwiftUI need not ever see anything high-frequency, so it shouldn't be getting bogged down.

If you're already doing that, then I'm not following. Perhaps some sample code would help.

[kamcma]

Oh: I think you want to be accumulating intermediate high-frequency emission state either in the dependency itself, or in Combine operators/async-algorithm operators/etc in the effect. If you accumulate them in the reducer's state as you say, that means you had to send them in with an action, and that's what you don't want to be doing: sending an action per high-frequency-emission. Regardless of whether you then observe that state in SwiftUI or not; that's orthogonal.

[pyrtsa]

The overload throttle(for:clock:reducing:) from swift-async-algorithms allows you to perform more refined combining than just latest/earliest (as in Combine). However, the precise semantics of swift-async-algorithms might not be what you expect or want in its current implementation.

[lightandshadow68]

One option would be to create an Effect with three endpoints. One receives and accumulates updates for batch processing, the second triggers processing the batch and a third returns an AsyncSequence that will iterate with the results of each batch. All of these can can be async, as to not block the main thread. A timer can be used to call the processing endpoint at the desired interval, which will return another set of updated results via the AsyncSequence when processing the batch is complete. That could trigger updates to the UI.

Alternatively, if it's a high-frequency issue, not just a load issue, the Effect itself could connect to the web-socket, and receive / submit high-frequency responses directly, without the need to run them though the reducer. Rather, only the processing trigger and results AsyncSequence would send actions to handle the results.