Long compilation times from the scoping function

[aj2109]

We have been noticing an extremely long compilation time in our project, and so I have been trying to investigate what is causing it. To verify what is causing this I have added -Xfrontend compilation times on the other swift flags, e.g. -warn-long-expression-type-checking=50. We have some SwiftUI views that are in some cases taking up to 20 seconds to compile. Breaking them down usually around half of that is the view itself, i.e. if I replace all the views with just Text("") it will half the compilation time, not much can be done to help that. But beyond that, there are often one or more usages of the TCA scope function and in removing one of them, it can cut the compilation time dramatically. Looking at the function it initially jumped out to me to likely be it's usage of generics.

To prove this point I added an explicitly typed scope function. Doing this in our actual project dramatically reduced the compilation time average, though there is a lot of noise in the actual project, so I went on to isolate this change, just a Text("") with as many view modifiers using a scope function as is necessary to get a large compilation time. I have attached this isolated example, where I have scopeStandard (which just replicates the TCA scope function's generic with return .constant(.none)), and scopeExplicit (which has made the params explicitly typed). if you clean and build you will see explicit scope around 30-50x faster to compile despite being called 4x more times. Undoubtedly it is expected that generic parameters will lead to a higher compilation time, but if this could somehow be made less extreme compilation times, it would dramatically decrease the projects overall compile times.

Interestingly, if you call the original scope function, i.e. scopeExplicit(...) { scope(...) } the compilation time is extremely low, basically no different to using the explicitly typed scope with it's return .constant(none). Which shows that the compiler has it's job made a lot easier if you narrow down the range of possibilities in the first function.

Any thoughts on what could be done to lower the overhead on the scope function if anything? In this isolated project it seems quite trivial but in complicated projects scoping 3-4 times can push the view nearly to compilation times which can no longer be done in a reasonable time.

Thanks!

CompileTimesSampleProject.zip

[mbrandonw]

Hi @aj2109, the way we recommend people support many destinations in a single view is to define a separate destination(store:) view method to colocate all of the navigation view modifiers:

struct StandardView: View {
  @Perception.Bindable var store: StoreOf<ExampleReducer>
  var body: some View {
    WithPerceptionTracking {
      Text("Hello, world!")
        .destinations(store: $store)
    }
  }
}

extension View {
  func destinations(store: Perception.Bindable<StoreOf<ExampleReducer>>) -> some View {
    navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
  }
}

That brings the compile times down to 1s for me (down for 6s+).

And if you further break it down into two destination helpers:

struct StandardView: View {
  @Perception.Bindable var store: StoreOf<ExampleReducer>
  var body: some View {
    WithPerceptionTracking {
      Text("Hello, world!")
        .destinations1(store: $store)
        .destinations2(store: $store)
    }
  }
}

extension View {
  func destinations1(store: Perception.Bindable<StoreOf<ExampleReducer>>) -> some View {
    navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
  }
  func destinations2(store: Perception.Bindable<StoreOf<ExampleReducer>>) -> some View {
    navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
    .navigationLinkDestination(
      item: store.scope(
        state: \.destination?.exampleReducerTwo,
        action: \.destination.exampleReducerTwo
      ),
      destination: ExampleViewTwo.init(store:)
    )
  }
}

…now it doesn't trigger a type check limit warning at all.

I'm not sure there is much we can do about the problem in general. It isn't too surprising that a concrete version of scope compiles much faster since the type checker doesn't have to do any work to figure out the generics. One idea we've had in the past to help would be to reduce the overloads of scope (which we already did once in the 0.x-to-1.0 release), but honestly your demo is showing that wouldn't even help much. Your standardScope method is not overloaded at all yet still exhibits the problem. So doesn't look like that approach will work.