Question about performance

[VladOrackle]

Since on iOS 17 the framework uses native Observation I suspect that brings all the performance benefits of more granular updates. But what about lower iOS versions? Comparing ObservableObject+@published vs Perceptible models what would be more performant?

[stephencelis]

@VladOrackle @Perceptible is simply a backport, so I think this would be a more general question that applies to @Observable vs. ObservableObject. We're not sure anyone has publicly done that research, and have only anecdotally heard folks claim that upgrading to @Observable improved their app performance, but if you find anything to share, we'd love to see it!

[BrentMifsud]

@stephencelis @mbrandonw

I have noticed some hangs with the perception framework when running the app in DEBUG configuration. Seems to happen when initially presenting a complex view with a very large Perceptible model.

I made sure to add @PerceptionIgnored to the properties that were originally not @Published just in case it was over observing or something.

Some things I noticed:

1. It only happens in DEBUG builds. In Release builds, the hang goes away.
2. if I remove WithPerceptionTracking the hang gets even worse
3. Bumping to iOS 17 and using the Observation framework directly, the hangs go away
4. these hangs were not present when the model was an ObservableObject

Unfortunately, instruments seems to fail to capture stack traces for these hangs (and only these hangs)... So I don't really know where in perception it's happening.

Since removing WithPerceptionTracking worsens the issue, I suspect it's related to the instrumentation that checks whether your view is wrapped in WithPerceptionTracking or not.

Unfortunately, since this is production code, I cant really share much. I'll see if I can make a simple project that reproduces the hang.

[BrentMifsud]

an update here, I was able to get a stack trace from instruments (hopefully its useful):

[BrentMifsud]

setting isPerceptionCheckingEnabled to false also seems to fix the issue.

[mbrandonw]

Hi @BrentMifsud, the library performs extra work in DEBUG mode in order to detect when you are accessing fields in a perceptible model without using WithPerceptionTracking. That work is non-trivial, and comes with a cost, but also it helps you catch potential problems. The stack trace you showed above consists of frames that are not compiled at all in RELEASE mode, and that is why this is not a problem for App Store builds.

You are free to turn off perception checking with the isPerceptionCheckingEnabled flag, but do be aware that that means you have the potential of accessing fields in a model without actually observing changes to it, and that will cause subtle bugs.

Or if you want to try to improve the performance of the perception checking then all the code is here. We will happily take a PR that improves the performance and passes the test suite.

[VladOrackle]

Interestingly it does seem to provide the same granular updates as the native Observation even on older OSes (I tested iOS 15.2)!

If I print changes inside the body using Self._printChanges() there is no body refresh when I change properties in my observable model that are not used in the View itself. Contrary to the ObservableObject which triggers body refresh even if I change @Published property that is not used in the body of the view

[mbrandonw]

Hi @VladOrackle, this library is the exact same code that powers Swift's Observation framework. We just copied and pasted the code from the open source Swift repo into an SPM module and made a few changes to make it actually distributable (and added a few touches of our own). So it should work exactly as if you are targeting iOS 17 and using Swift's native observation tools. And it should work on iOS 13 and 14 too 🙂