This seems to be correct:
@Observable class Box<T: Equatable> {
var value: T? {
didSet {
self.count += 1
}
}
@ObservationIgnored var count = 0
}
let box = Box<Car>()
let c1 = Car(name: "1234")
box.value = c1
let c2 = Car(name: "1234")
box.value = c2
precondition(box.count == 2)
Passes on 6.0 and breaks on 6.2.
@Philippe_Hausler it looks like we are targeting 2025-04-02 for a release/6.2 branch. Would you have any interest in collaborating on something like a "retroactive" evolution pitch for the shouldNotifyObservers changes? Would it be possible to see if the community had any more ideas that might lead to some potentially different implementations for shouldNotifyObservers before this goes to production later this year?
Sure, if you want to put together a pitch document about it id be happy to help out give context and information of the impact and design decisions around it. If anything it might be best for just bookkeeping of what has changed.
Feel free to hit me up as a review on a pre-pull-request even for getting that together.
*as a side note; now that the Observed pitch is live - that is one of the major reasons to have that modification btw. While testing that before pitching we basically found that most folks needed to add in the uniqueness checks and a lot of other projects were already doing that for perf reasons for SwiftUI anyhow.
For now I was thinking of something a little more lightweight. Just a post in the Evolution page for some more traffic on the discussion that started here:
release/6.1 is cut?main.shouldNotifyObservers code and spend more time talking about options.shouldNotifyObservers before the branch cut.Either way I strongly recommend for someone to write the detailed documentation on this feature before it goes live to prod… but documentation diffs can patch after the branch cut without much trouble. But product engineers should have some definitive source to learn from when they compile their code with the 6.2 toolchain and certain behaviors of Observable objects has changed.
@Jon_Shier A diff landed to address this:
By any chance did you have any more details you might be able to share publicly about how these changes to Observable affected SwiftUI performance? Are there any publicly available benchmarks or measurements we made to quantify how these changes improve SwiftUI performance? What would be our test group? What would be our control group? Is there one specific sample application project you can share that is a good place for us to measure performance with these changes?
This pitch:
Gives us an additional hook to try and optimize the performance of Observable. This change would enable us to migrate something like this:
private nonisolated func shouldNotifyObservers<T>(_ lhs: T, _ rhs: T) -> Bool {
true
}
private nonisolated func shouldNotifyObservers<T: Equatable>(_ lhs: T, _ rhs: T) -> Bool {
lhs != rhs
}
private nonisolated func shouldNotifyObservers<T: AnyObject>(_ lhs: T, _ rhs: T) -> Bool {
lhs !== rhs
}
private nonisolated func shouldNotifyObservers<T: Equatable & AnyObject>(_ lhs: T, _ rhs: T) -> Bool {
lhs != rhs
}
To something like this:
private nonisolated func shouldNotifyObservers<T>(_ lhs: T, _ rhs: T) -> Bool {
true
}
private nonisolated func shouldNotifyObservers<T: Equatable>(_ lhs: T, _ rhs: T) -> Bool {
if let isKnownIdentical = lhs.isKnownIdentical(to: rhs) {
return isKnownIdentical
}
return lhs != rhs
}
private nonisolated func shouldNotifyObservers<T: AnyObject>(_ lhs: T, _ rhs: T) -> Bool {
lhs !== rhs
}
private nonisolated func shouldNotifyObservers<T: Equatable & AnyObject>(_ lhs: T, _ rhs: T) -> Bool {
if let isKnownIdentical = lhs.isKnownIdentical(to: rhs) {
return isKnownIdentical
}
return lhs != rhs
}
Instead of blocking our observation notification on a check for value equality… we now have the option to "fast-path" and check for identity equality. We can also fall back to the 6.2 behavior and check value equality if the type we are observing does not have any concept of equality by identity: like an Int or a Bool.
Before we put this proposal through evolution it might be helpful for the LSG if we had some "real world" impact we can show to demonstrate why this proposal should ship on Equatable. If we could point back to SwiftUI performance improvements… that would be very impactful. If we could then also point back to the same suite of benchmarks and measurements that we referenced before shipping shouldNotifyObservers with value equality that would be even more impactful.
So the measurements were measured by adding up re-calculation times of each update; this adds up to real world impact to scrolling performance or other such time sensitive re-renders (often Text and specifically variable widths/heights associated with resizes and wrapping are a big cost of recalculations). Reducing spurious re-renders has always been something the folks working on SwiftUI itself have been sensitive to and many of the performance improvements go hand in hand with other changes beyond just Observation itself.
The isKnownIdentical might add some advantage, but that is probably shaving off nearly immeasurable amounts in real world scenarios now (with those other changes that landed), but I could see some extreme cases that use observations of arrays of strings being rendered to Text that might trip it up. It would need some measuring and experimentation to determine how much it really impacts things.
One tool that might also be useful is the SwiftUI instruments tool - that was definitely a critical mechanism to measure some of these things.
That all being said: one issue that might be a problem is that any call-out there must have an available deployment - because the macro itself cannot determine the appropriate availability guards (so keeping it as general as possible or back-deployable as possible is very much preferred). As a cautionary tale; I tried to add a KeyPath caching system and that ended in some severe regressions that made us have to back it out and re-evaluate how to approach the performance of Observation and SwiftUI.