Reducer switch and SwitchStore build times taking too long

[Alexsilvacodes]

Good day everyone 🖖

We introduced SCA in our current project last year and we have been growing in features using it, which led to increasing build times on it, which should be normal, but we realized when analyzing the origin of those build times, that the sources of those build times were mainly two:

• Some switch reducers, meaning inside there could be some huge tasks going on or just complex ones.
• Almost all the SwitchStores that we currently have on the views.

To give a bit more context, we are using currently swift-composable-architecture version 0.33.1 and how the architecture looks: we have the concept of feature that 99% of the times translates to a View (with a few exceptions where there are features without a View). We have an App environment as well as local environments with specific services for those.

Current build times:

Is this something already known/fixed?

If you have any suggestions questions feel free to reach out 🙏

[tgrapperon]

Hello!

You can add a few build flags to get a better local view of what's taking time to build (see https://www.jessesquires.com/blog/2017/09/18/measuring-compile-times-xcode9/ for example). The app you're showing above requires you to rebuild everything from a clean slate which is quite inconvenient when iterating to improve the situation.

From my experience, and for unoptimized builds, most of the time spent for compilation is caused by type checking, and you can often solve your issues by simply casting variables to help the compiler.

For example, you can try to specify return types of closures if possible.
If you are performing numerical calculations, you can try to explicitly cast each variable to its type and use floating-point literals (like 1.0) instead of 1 for floating-point numbers. It seems silly, but I had files taking 20s to compile merely because I was doing something like let x = 10 + 2 * cos(3 * .pi / 5) + 4 only once, and reduced to almost nothing by using let x: Double = 10.0 + 2.0 * cos(3.0 * Double.pi / 5.0) + 4.0).

Also, be wary of operators. They're usually overloaded a lot and ,IIRC, are allowed a few more levels of checks which adds up to the compilation time. The kind of issue in the line above is partly caused by them.

If reducers are taking too long, you can extract some cases using functions of state and environment (technically, other reducers focused to one action only):

let reducer = Reducer { state, action, environment in
  switch action {
  case let myAction(value):
    return handleMyAction(value: value, state: &state, environment: environment)
  }
}
func handleMyAction(value: Int, state: inout State, environment: Environment) -> Effect<Action, Never> {
  …
}

Using this approach, you should be able to spot more easily if something is taking a particularly long amount of time. I don't remember if it would present warnings for local functions you would define in the reducer, but it will surely do for top-level/first-level ones. This can be easily checked once you have a candidate that rises a warning.

You can adopt the same approach with SwiftUI, and extract branches as individual views.
The objective is not to directly fix build time issues (although it may already help), but to check if there are bottlenecks that are requiring more attention.

[tgrapperon]

Also, the issue with SwitchStore is possibly caused by the large number of overloads it has to reinstate some form of exhaustivity when switching over cases. I'm not sure there's a way around this for now.

[tgrapperon]

You can check the effect of these overloads by copy/pasting the following somewhere in your project replacing SwitchStore with _SwitchStore and CaseLet by _CaseLet. This is merely an unchecked variant of SwitchStore that you shouldn't use, but if it clearly improves when using it, it would be a clear indicator of the source of the issue.

public struct _SwitchStore<State, Action, Content: View>: View {
  public let store: Store<State, Action>
  public let content: () -> Content

  public init(
    _ store: Store<State, Action>,
    @ViewBuilder content: @escaping () -> Content
  ) {
    self.store = store
    self.content = content
  }

  public var body: some View {
    self.content()
      .environmentObject(_StoreObservableObject(store: self.store))
  }
}

public struct _CaseLet<GlobalState, GlobalAction, LocalState, LocalAction, Content: View>: View {
  @EnvironmentObject private var store: _StoreObservableObject<GlobalState, GlobalAction>
  public let toLocalState: (GlobalState) -> LocalState?
  public let fromLocalAction: (LocalAction) -> GlobalAction
  public let content: (Store<LocalState, LocalAction>) -> Content

  public init(
    state toLocalState: @escaping (GlobalState) -> LocalState?,
    action fromLocalAction: @escaping (LocalAction) -> GlobalAction,
    @ViewBuilder then content: @escaping (Store<LocalState, LocalAction>) -> Content
  ) {
    self.toLocalState = toLocalState
    self.fromLocalAction = fromLocalAction
    self.content = content
  }

  public var body: some View {
    IfLetStore(
      self.store.wrappedValue.scope(
        state: self.toLocalState,
        action: self.fromLocalAction
      ),
      then: self.content
    )
  }
}

private class _StoreObservableObject<State, Action>: ObservableObject {
  let wrappedValue: Store<State, Action>

  init(store: Store<State, Action>) {
    self.wrappedValue = store
  }
}

[Alexsilvacodes]

Hey @tgrapperon thank you for you tips. We've already used the flags that you mention and made some improvements on the type check, but we are not sure how to solve the type-checking for the SwitchStoreand also the IfLetStore.

This is an example of the amount of time that type-check takes for a combine IfLetStore with a SwitchStore within.

---

This other example contains a SwitchStore with only 1 CaseLet.

We will investigate what you pointed out in relation with the _SwitchStore 🙏

[tgrapperon]

This is great that you're making progress! A few additional comments:

• The _SwitchStore I'm proposing is for inspecting compilation duration only. If the duration goes down by a lot, this is a sign that the regular SwitchStore probably needs more attention. If it isn't, it means that the issue is elsewhere.
• It is possible that the IfLetStore>SwitchStore situation could be improved if the use-case is unwrapping and then switching over a Route?. I'll experiment with this.
• As an aside, your usage of topLevel>WithViewStore>IfLetStore is a little suspicious. It doesn't cause problems in terms of compilation duration (it seems to resolve in 2ms), but it seems a little odd: does something in IfLetStore needs the ViewStore to present its data? If not, you can probably remove the WithViewStore or push it down closer to where it is needed. Same with your use of Group inside the ViewStore: do you use Group dispatching of modifiers or do you have more than 10 children in it? Again, probably not something that will drastically change the compilation duration, but also potentially not required. This makes me think that a few overloads for WithViewStore were added relatively recently. Can you check how long it takes if you build your project by pinning TCA to 0.35.0? This is the last version without these overloads. Hopefully, you haven't used new API's introduced since and it would build without changing a line of code.

[mbrandonw]

Bummer to hear about the compilation performance problems. An idea Stephen and I just sketched out is using a dedicated @SwitchStoreBuilder to greatly improve the overload situation.

We wouldn't be able to release this in the library until Swift 5.7 lands, but it seems like it would work well, and allow for any number of a CaseLet's inside a SwitchStore.

[Alexsilvacodes]

Thank you for the heads up @mbrandonw . For now we are just trying to improve those build times so is not blocking any progress, just raised the discussion in order to understand the status on this matter 🙏