Improving performance of perception checks when using Perception

[scogeo]

Several of us have noticed performance issues when using the new Perception backport on iOS 16 or earlier. The performance issues seem to only affect DEBUG builds and can be traced down to frequent calls to perceptionCheck() which provides the purple runtime warnings in Xcode when perception is used incorrectly. This is an amazing diagnostic tool to have, but the current performance cost as implemented make is impracticable to use in complicated real world applications.

I have done some experiments on this already and looked at a few options to improve performance including some type of memoization to cache the results of perception check calculations and eliminating perception checks when called from inside a reducer.

I will include copies of the above posts below.

[scogeo]

I'm sharing some of my findings on the performance of the perceptionCheck() code when using WithPerceptionTracking on iOS 16 in the simulator. The sample app I used for these investigations was a a fork of SyncUps that includes WithPercpetionTracking and iOS 16 support.

I did my own quick and dirty instrumentation using a DEBUG build (and without _printChanges()) to see how many calls of perceptionCheck() were being made and how much time they were taking. The use case is to launch the app, press the Add button to create a new SyncUp. After the sheet appears and has focus, I measure how many calls and time in perceptionCheck() after typing a single character in the focused Title field. I did this both with and without a WithPerceptionTracking wrapper in the SyncUpForm body.

The table below shows the two use cases and how many times perceptionCheck() was called and some of the conditions under which it was called. I manually analyzed the call stack frames in the debugger to classify calls of .isInSwiftUIBody as to whether they were coming from a reducer or not. (Test machine is an M2 Pro)

Test Case	.isInPerceptionTracking true	.isInSwiftUIBody called from Reducer call stack	.isInSwiftUIBody called from non-Reducer call stack	Total calls to perceptionCheck()	Total Time spent in perceptionCheck() (secs)
No use of WithPerceptionTracking inbody	0	34	10	44	0.73
WithPerceptionTracking used in body	7	34	18	59	0.75

From this simple use case, there is a lot of computation going on to perform the perception check. This results in a severe degradation in performance and explains why typing in a text field in the simulator is painfully slow with 0.75 seconds of computation per keystroke.

The good news is the main culprit seems to be the unnecessary perception checks inside of reducers. Reducer call stack frames are particularly large and also have very complicated mangled names. So not only are they responsible for over 75% of the calls to perceptionCheck() in this use case, they probably also are the most computationally expensive of those calls. The non-reducer calls had fewer stack frames and far simpler symbol names to demangle.

Although this use case was a simple interactive UI use case, any heavy use of read access on observed state inside a reducer is going to incur a large penalty when running the perception back port in DEBUG mode due to the perception check.

Since we don't care about read access of observed state in a reducer for the purpose of the perception check, it seems that there is some low hanging fruit to detect if perceptionCheck() is being called from inside a reducer call stack through perhaps a TaskLocal variable and then skip the complex isInSwiftUIBody code for those calls.

Thoughts?

Originally posted by @scogeo in #2594 (comment)

[scogeo]

I did some more digging on the performance issue on DEBUG builds when using WithPerceptionTracking and it seems the main culprit is in inSwiftUIBody defined in PerceptionRegistrar. I did a real quick and dirty memoization implementation as follows and performance became acceptable:

  fileprivate var memoizedResults: [AnyHashable: Bool] = [:]

  var isInSwiftUIBody: Bool {
     // Check cache
      let addresses = Thread.callStackReturnAddresses
      if let memoizedResult = memoizedResults[addresses] {
          return memoizedResult
      }

      for callStackSymbol in Thread.callStackSymbols {
      guard
        let symbol = callStackSymbol.split(separator: " ").dropFirst(3).first,
        symbol.utf8.first == .init(ascii: "$"),
        let demangled = String(symbol).demangled,
        demangled.hasPrefix("protocol witness for SwiftUI.View.body.getter : ")
      else { continue }
      // update cache
      memoizedResults[addresses] = true
      return true
    }
    // update cache
    memoizedResults[addresses] = false
    return false
  }

This was just a quick hack to take a stab at the problem and doesn't take into account threading, etc. but there is clearly some room for improvement here. But with this quick hack I was able to at least fully exercise my app in the simulator when it was previously nearly unusable due to the lag.

Originally posted by @scogeo in #2594 (reply in thread)

[scogeo]

@mbrandonw I can put together a PR against the observation-beta branch if you'd like. I think excluding perception checks inside of reducers will provide the biggest win and seems straightforward to implement.

[scogeo]

Since I started this discussion, 3 PRs (#2622, #2630, and #2649) have been merged into the observation-beta branch. I just pulled the latest changes and I'm happy to report that for my moderately complex app, performance is excellent when running DEBUG builds on the simulator on iOS 16.

[mbrandonw]

Great, thanks for helping out with that!