How does SwiftUI invalidate its dependency graph?

[tgrapperon]

In discussion #1012 and PR #1015, we refined our understanding of the way SwiftUI invalidates its dependency graph, that is, how it detects that things have changed and some View deserves to run its body again. It does so by inspecting if some view's stored properties have changed between two updates, most likely by comparing the memory representation of each stored value.

I understand how it can happen for plain old values like structs, but I don't know how it works for closures that are stored and lazily run in body. Experience suggests that SwiftUI is able to compare the memory representation of each value captured by the closure, and decides that if they coincide, the result will be the same and the dependency graph should be preserved at this node. This is under this assumption that #1015 was implemented.

I don't know how it can happen (or if it happens at all), nor if this is some Swift feature rather than something specific to SwiftUI.

Does anyone have an idea how it works under the hood?
I'm only asking by curiosity.

[iampatbrown]

@tgrapperon my guess it that one of the inputs taken into consideration when determining if a view needs to be recalculated is the body's captured values.

While experimenting I created this helper:

struct Closure {
  var ptr: UnsafeRawPointer
  var capturePtr: UnsafeRawPointer?
}

extension View {
  func debugCapturedValues() -> some View {
    let closure = withUnsafePointer(to: self.body) {
      $0.withMemoryRebound(to: Closure.self, capacity: 1, \.pointee)
    }
    print(
      "\(Self.self).body: \(closure.ptr) captured: \(closure.capturePtr.map { "\($0)" } ?? "none")"
    )
    return self
  }
}

Using the counter example:

class Counter: ObservableObject {
  @Published var count: Int = 0
}

struct CounterView: View {
  @ObservedObject var counter = Counter()

  var body: some View {
    Stepper(onIncrement: { self.counter.count += 1 }, onDecrement: { self.counter.count -= 1 }) {
      Text("\(self.counter.count)")
    }
    .debugCapturedValues()
  }
}

Interacting with the stepper results in the following:

Stepper<Text>.body: 0x000000010cdd2e10 captured: 0x0000600000bbfc40
Stepper<Text>.body: 0x000000010cdd2e10 captured: 0x0000600000bb50a0
Stepper<Text>.body: 0x000000010cdd2e10 captured: 0x0000600000bb5d00

Doing the same using WithCounter:

struct WithCounter<Content: View>: View {
  @StateObject var counter = Counter()
  @ViewBuilder var content: (Counter) -> Content
  var body: some View { self.content(self.counter) }
}

struct WithCounterView: View {
  var body: some View {
    WithCounter { counter in
      Stepper(onIncrement: { counter.count += 1 }, onDecrement: { counter.count -= 1 }) {
        Text("\(counter.count)")
      }
      .debugCapturedValues()
    }
  }
}

results in the following:

Stepper<Text>.body: 0x000000010cf43a20 captured: 0x00006000034074c0
Stepper<Text>.body: 0x000000010cf43a20 captured: 0x00006000034074c0
Stepper<Text>.body: 0x000000010cf43a20 captured: 0x00006000034074c0

Notice how the captured address doesn't change. In this case, that address points to the counter inside WithCounter

I'm not sure if this is what SwiftUI does under the hood it's more to demonstrate that it's a possibility.

[iampatbrown]

So that's how closures are laid out!

My example isn't exactly correct. You would need to transform var capturePtr: UnsafeRawPointer? into something that better represents the captured values. We're only really seeing the first captured value for Stepper.body, which is for onIncrement.

Right now, I'm supposing they memcmp the whole view value, and in case of difference

I think that will be one element of it. My guess is that the view and it's properties (including .body) will be processed using the most suitable method available. One of the reasons I suggested using a new class instance instead of a struct/property wrapper is because I suspected it would then perform an additional equality check on state, which I felt wasn't necessary seeings that is already handled by the ViewStore

If you change StoreWrapper in @stephencelis example to a class it will fix the problem. You can also add an additional property to the struct and override the Equatable conformance to always fail like so:

struct StoreWrapper<State, Action>: Equatable {
  private let void: Void = ()
  var store: Store<State, Action>

  var send: (Action) -> Void { self.store.send }
  var state: State { self.store.state }

  static func == (lhs: Self, rhs: Self) -> Bool {
    false
  }
}

I believe a single value struct wrapping a class is going to use === instead of == which is why adding the void is required to force the Equatable check and @stephencelis single value example doesn't work because var store: Store<State, Action> isn't changing.

[lukeredpath]

I'm unsure if this is related but mentioning here in case it's useful - I have also seen strange behaviour when storing closures in the SwiftUI environment - over rendering in this case. Wrapping those closures in a struct - like a lot of built in closure type values - solves the problem.

https://twitter.com/lukeredpath/status/1491127803328495618

It seems SwiftUI behaviour is undefined or unpredictable when storing a closure directly in the environment. I don't know if this behaviour is intentional and limited to closures or any reference types. SwiftUI does expose some reference types through the environment out of the box (like NSManagedObjectContext) but it does make me wonder why a lot of closure values are wrapped in callable Structs instead (and Apple has changed some to use this pattern too).

There's a lot of discussion here about how SwiftUI evaluates view identity before calling its body - there is also a way to explicitly control this IIRC and that is by conforming to EquatableView and defining equality. Is there some way this can be leaned on to bypass whatever SwiftUI does by default?

[tgrapperon]

@lukeredpath, do you define your closure at the very top of your view hierarchy? If not, each time the body where it is defined runs, a new reference will be created in .environment(_:,_:), invalidating the dependencies of the views that are surfacing this environment value[Edit: Sorry, I just read the responses to your tweet]. There are maybe specifics with the way it works for Environment though, so the behavior may be indeed slightly different. Maybe we should experiment more with different built-in property wrappers to draw a clearer picture.

EquatableView is indeed something that can help explore what really happens. If I understand correctly, it allows delegating the response of "Did the body of content change?" to "Did content change?". So the change of content is detected, equality is checked and in case of failure only, content.body is evaluated.

I guess that in the general picture, the memory of the View value is compared instead. I don't personally think that its body is involved: If all the dependencies of a View are identical (that is, all stored properties (wrapped or not)) are identical, the body cannot be different. I think this is a two steps process that involves checking the stored "raw" properties, and the invalidation status of DynamicProperty's. The update() requirement and the "Demystifying SwiftUI" WWDC talk are suggesting that such properties are lazily evaluated. They only have to hold onto some isInvalid flag (or maybe something more subtle). If the flag is raised, the property is assumed to have changed enough to warrant body evaluation. All these DynamicProperty are tied to the view's identity/lifecycle. It seems manageable to maintain a register of these properties' invalidation status, as suggested by the

  static func _makeProperty<V>(in buffer: inout SwiftUI._DynamicPropertyBuffer, container: SwiftUI._GraphValue<V>, fieldOffset: Swift.Int, inputs: inout SwiftUI._GraphInputs)

requirement of DynamicProperty that is provided by default. I'm reading it as

• buffer: inout _DynamicPropertyBuffer -> Storage of the properties' invalidation status (and maybe other metadata);
• container: _GraphValue<V> -> The view's (or scene/windowGroup, etc) identity;
• fieldOffset: Int -> The index of the DynamicProperty in its parent's declaration (using reflection maybe). Combined with the view's identity, this should provide a stable identifier for the property.
• inputs: inout _GraphInputs -> ??? Maybe the view's dependencies or something related to it, in order to determine their orbits more efficiently.

But this is mostly a guess, and this is indeed a gray area.

Maybe we could indeed gather more insight using EquatableView, AnyView, and some custom DynamicProperty

[tgrapperon]

@lukeredpath Great find with the callAsFunction thing BTW! It is maybe specific to EnvironmentValues and the way SwiftUI can efficiently override values. I don't know if transformEnvironment(_:transform:) would work the same and offer the same optimization routes with reference types. It does with mananagedObjectContext, but this is a nominal type that is Equatable. As I'm getting it, the inout is "copy-in/copy-out" and that may change the reference of a provided closure.
I need to check this though.

[tgrapperon]

I don't think that inout arguments are involved now, but memcmp returns different values with the same closure:

var f: () -> Int = { 3 }

struct S {
  var f: () -> Int = { 3 }
}
var s = S()

class C {
  init() {}
}
var c = C()

memcmp(&f, &f, MemoryLayout.size(ofValue: f)) // != 0
memcmp(&s, &s, MemoryLayout.size(ofValue: s)) // 0
memcmp(&c, &c, MemoryLayout.size(ofValue: c)) // 0

It would mean that if SwiftUI is using memcmp¹ on Environment values to check for updates, it will see the closure as something that changed. This seems compatible with your observation of over-invalidation, and that could also explain why they wrap closures in structs that are called as function, and why existentials like managedObjectContext don't cause issues.
I'm not versed enough into low-level Swift to tell why it behaves like that with closures though².

Footnotes

1. I'm talking a lot about memcmp because I remember a SwiftUI engineer mentioning it was something they were using when diffing states. ↩

2. As I was looking for answers to this question, I stumbled over this thread where Joe Groff gives some insight into SwiftUI internals. I haven't had the time to read everything thoroughly yet, but it looks quite interesting. ↩