Performance issues

[maximkrouk]

Hi, I'm using RAS-TCA and I'm facing noticeable performance issues. The app has about 40 modules and a large number of actions, the state is pretty large too. Partially issues may not be connected with TCA itself, but some of them may relate.

I created the thread for discussing ideas on how to improve the performance and to keep the history of the performance improvement process reachable for myself and other developers.

The App

Issues

• High CPU usage
  • Laggy scroll
  • Device temperature

Possible reasons

• AVPlayer
• CasePaths
• Amount of reducers
• ReactiveSwift (Link 1, Link 2)

[maximkrouk]

The first step is AVPlayer improvements, we didn't fix it completely, but extracting most of the player logic to a background thread and moving player setup from cellWillAppear to scrollViewDidDecelerate noticeable improved scroll performance, but anyway it's not perfect yet.

AVPlayer notes can be found here

Btw player is not an environmental dependency, but a shared instance for the app, player states are stored in feed elements' states and FeedItemStore for each FeedItem is scoped to playerStore and set to the player on scrollViewDidDecelerate

[maximkrouk]

Tomorrow I'll try to generate custom CasePaths for all of our Actions, and reply here if it fixes any issues or not.

[stephencelis]

Let us know if this is the culprit. We're exploring improving the reflection mechanism soon, but it'd be helpful to have some data points.

[maximkrouk]

Couldn't generate it yet, seems like I need a little more time to implement it.

[maximkrouk]

Well, basic script is done, I'll fix a few issues, cleanup the API and publish it this week.
Also, I integrated generated CasePaths into a project, seems like it partially improved app performance, but I'll show the update to my team and give you a feedback tomorrow.

[maximkrouk]

Well, the app works a bit better on iPhone 11, but 5s/6 are still laggy

[maximkrouk]

Also, my colleague proposed to use a serial background scheduler for all of the application logic and only observe UI logic on the main thread (and also send actions on the same background scheduler)
@mbrandonw, @stephencelis, @mluisbrown, what do you think about this approach?

[AlexisQapa]

IIRC there was a previous discussion doing so for some kind of headless TCA. AFAIK there is no issue as long as you don't use features like animations which should be run on the main queue.

Thought I think your reducer shouldn't be that slow maybe you are doing too much like sorting big arrays which could be done on a background queue as an effect and keep your stone one the main queue.

[maximkrouk]

Well, it's the next step, so we'll try to move our reducers to a background scheduler and reply here if it works fine

[maximkrouk]

We moved appLogic to a background thread and it increased app performance a lot (even iPhone 5S works almost smoothly).

But now UI is significantly faster than logic, so scroll events, for example, are processed some time after scroll and new actions can be processed only after all previous ones are processed (it can take more then 30s to process them 😠)

We'll try to investigate it a bit more and maybe throttle some actions or use ComposableCollectionView with a local (non-scoped) store. But I'm not sure, that this behavior (fast ui, slow logic) won't lead to some new issues 🤔

[shawnkoh]

We moved appLogic to a background thread and it increased app performance a lot (even iPhone 5S works almost smoothly).

But now UI is significantly faster than logic, so scroll events, for example, are processed some time after scroll and new actions can be processed only after all previous ones are processed (it can take more then 30s to process them 😠)

We'll try to investigate it a bit more and maybe throttle some actions or use ComposableCollectionView with a local (non-scoped) store. But I'm not sure, that this behavior (fast ui, slow logic) won't lead to some new issues 🤔

Hi! Do you mind sharing how this has worked out for you?

[maximkrouk]

@mluisbrown, we experimented a bit and moved our app logic to background thread, and achieved smooth scrolling, but the first issue (not related to rac-tca, since we had to send actions asynchronously anyway to avoid deadlocks) is that depending on implementation you may lose some sync-ability, not critical in most of scenarios, but just a thing to note. The second and the one that made us revert changes is that even if UI is not affected by store performance bottlenecks, stacking actions could add up to multiple seconds and any interaction is delayed by the time of executing already-sent actions.

There were multiple things that drained the performance afaiu. The first is sending actions too frequently, it can be partially solved by extracting critical parts of the global state or throttling actions from UI layer. The second is probably using StorePublisher's dynamicMemberLookup for triggering collectionView updates which causes more complex equations than just publisher[dynamicMember: \.items.count].

So the conclusion is:

• Switching to background stores may improve UI performance, but leads to another problems, so we decided to keep stores on the main thread
• Try reduce the amount of actions in critical parts even if it can be a little bit inconsistent in terms of architecture
• Some updates can be less time consuming if removeDuplicates is used more frequently, but on a simpler substate, but it's related more to UIKit, than SwiftUI, since in SwiftUI this mechanism allows you to avoid redundant View updates.

UPD:
I replied to mluisbrown (he wrote the first, not the last comment 😅) instead of replying to @shawnkoh accidentally 🌚

[ferologics]

From my experience the performance hits the fan with TCA whenever you send many actions through multiple layers of pullback reducers. I.e. calling onAppear/Disappear from a scoped ViewStore can be super expensive when it has to bubble up and down a app > chat > message reducer chain. For this reason we had to postpone the dynamic content prefetching implementation (that depended on the onAppear/Disappear actions of each list item). Sending that many actions via our reducer chain (with just 3 pullbacks) was a big performance bottleneck and made the list very choppy/unusable.

Screenshot of trace

TCA_prefetching_trace.trace.zip

[mbrandonw]

We have some changes coming to TCA soon that will improve the performance related to .scope and view store observations, and we are in the early stages of experimenting with a more performant form of case path reflection. We'd be really curious to see how your instrumentation data changes after using those changes. Will have an update soon!

[ferologics]

@mbrandonw 👌 it should be as easy as re-enabling the currently disabled prefetching implementation -- I can also help benchmark some pre-release version/branch. The code is frozen ATM so any performance improvements should be visible.

[mrackwitz]

@mbrandonw How are these changes coming along? Is there anything I could test drive or support with?

[stephencelis]

@mrackwitz We just pushed a performance-tweaks branch that aggregates a few upcoming changes:

• Some cleanup to store.send to coalesce multiple mutations for synchronous effects into a single mutation, which means fewer emissions of state to downstream publishers
• Some cleanup to store.scope to avoid extra evaluations of the toLocalState transform function
• Some cleanup to ViewStore to avoid extra equality checks
• Some enhancements to Case Path's extract function that should boost extraction performance by over 2x on successful extraction, and up to 100x faster on failed extraction.

The first 3 updates we've been testing and plan to release on Monday, so any early feedback would be helpful. The CasePath change is a more recent endeavor so we'll be giving it another week.

[mrackwitz]

@stephencelis Thanks for sharing. This looks very promising. I'll try to have a look into this soon and will report feedback.

[maximkrouk]

Btw we migrated to the original TCA this weak, so we'll be able to check performance tweaks branch soon 😎
Also, I had no time to improve our CasePath generation script, but it's already available on https/GitHub.com/edudo-inc/spmgen casepath branch 🙂