Performance Issue: Scrolling Lag in ForEach with Store Scope

[jasin755]

Description

I encountered a performance issue on a regular listing using the standard TCA approach (when scrolling quickly, the list starts to chop and skip lines):

ForEach(store.scope(state: \.components, action: \.component)) { store in
	CellView(store: store)
}

Interestingly, I found a workaround that will rapidly improve performance:

let storeScope = store.scope(state: \.components, action: \.component)
ForEach(0 ..< storeScope.count, id: \.self) { index in
	let store = storeScope[_offset: index]
	CellView(store: store)
}

Original discussion: https://pointfreecommunity.slack.com/archives/C04KQQ7NXHV/p1739455053227119

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Reproducing project

Here I have prepared a simple sample project where you can reliably simulate and test both approaches:
https://github.com/jasin755/tca_slowlist

The Composable Architecture version information

1.17.1

Destination operating system

iOS 18

Xcode version information

16.2

Swift Compiler version information

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx15.0

[DominikGrodl]

+1

I came across the same issue on one of my projects recently. I have an "infinite" list and I was experiencing issues when users were scrolled down and tapped the tab icon/top title to scroll back to the top. In those instances, depending on how far the users were scrolled, the app froze for a noticeable time. This is not present in vanilla SwiftUI app powered by an Observable object.

[mbrandonw]

Hi @jasin755, I believe you are simply seeing the effects of all SwiftUI views being wrapped in an AnyView in debug builds of apps. This was added in Xcode 16 to improve previews, but it does have problems as you are seeing here.

To prove this to yourself, put a print statement in the body of the CellView. You will find that all 300 views are "rendered" immediately. That isn't the behavior one would expect from a List and ForEach. Instead, you would hope that a row's body is computed only when that row comes onto the screen. The AnyView makes this kind of behavior impossible, and so you get worse performance.

If you run your app in release you will find that only the rows that are visible have their body's computed, and you will find that the performance is much better.

Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[klememi]

Thanks @mbrandonw for explanation, it makes sense and works exactly like you've written, but I still don't understand how that small adjustment significantly improves performance. In our real-life app, just with this small change we can fix extremely laggy list (in release build)

[mbrandonw]

Hi @klememi, I would need to look into it more, but I believe the change you made causes the store to eagerly create all of the stores for each row. We go through great lengths to make the _StoreCollection lazy to prevent that, but there may be tradeoffs to doing so.

FWIW, another way to eagerly create the stores is to simply do:

ForEach(Array(store.scope(…))) { store in 
}

In fact, this is what we suggest people to do when they use ForEach in a lazy view container, because in that situation the trailing closures can be called on background threads causing stores to be created on background threads.

In a future version of TCA we will be able to get rid of this lazy store collection thing and simplify things quite a bit. But there's work to be done before we can do that.

[MartinStrambach]

@mbrandonw Could you please give an example what you mean by because in that situation the trailing closures can be called on background threads causing stores to be created on background threads.?

[mbrandonw]

Hi @MartinStrambach, sorry I was being imprecise. It's access to the collection in the ForEach that can happen off the main thread. We have a note about that here:

swift-composable-architecture/Sources/ComposableArchitecture/Observation/IdentifiedArray+Observation.swift

Lines 110 to 120 in 688802c

	precondition(
	Thread.isMainThread,
	#"""
	Store collections must be interacted with on the main actor.
	When passing a scoped store to a 'ForEach' in a lazy view (for example, 'LazyVStack'), it \
	must be eagerly transformed into a collection to avoid access off the main actor:
	Array(store.scope(state: \.elements, action: \.elements))
	"""#
	)

To test this you could create a custom collection type that wraps an array and prints the thread in the subscript(position:). When used in a lazy view container and ForEach you will find that access happens off the main thread. It may not always happen, but it can..

[jasin755]

@mbrandonw I tried wrapping store.scope(...) in Array() and at the same time added print to the body of CellView and from the output I can see that it creates lazy. I understand correctly that wrapping store.scope(...) in Array() creates eager only stores, but views are still lazy?