Cache bridge deserialization

[BeyondiOS]

struct User3: Codable, Defaults.Serializable {
    let name: String
    let age: String
}

extension Defaults.Keys {
    static let user3 = Key<User3>("user3", default: .init(name: "Hello", age: "24"))
}
...
    func test2() {
        print(Defaults[.user3])
        print(Defaults[.user3])
    }
...

The above code will call bridge.deserialize twice. If user3 is an array and there are many attributes of the User3 type, will it affect performance?

Would it be better to cache the data after Defaults[.user3] is executed once?

extension Defaults.Serializable {
	....
	static func toValue(_ anyObject: Any) -> Self? {
		// Return directly if `anyObject` can cast to Value, since it means `Value` is a natively supported type.
		if
			isNativelySupportedType,
			let anyObject = anyObject as? Self
		{
			return anyObject
		} else if let value = bridge.deserialize(anyObject as? Serializable) {
			return value as? Self
		}

		return nil
	}
        ....

[sindresorhus]

It can affect performance yes, if the data is large and you're calling it many times in a loop. But in common cases, it should not be a problem. You should not store huge amounts of data in UserDefaults anyway.

I do think we should look into caching the deserialized data using an LRU cache.

Actually, the first thing we could do is to simply cache all calls for 5 seconds. That way, we can make sure that we don't waste time on deserializing things that are called in a loop.

[trevorturk]

I just wanted to note that I'm working around this issue with a cache that gets read in the getter and reset in the setter, just an example for illustrative purposes, could be worth considering as a generic feature?

import Foundation

@MainActor
class WeatherManager: ObservableObject {
    static let shared = WeatherManager()
    private init() {}

    private let savedDataManager = SavedDataManager.shared
    private var cachedData: Weather?

    var weather: Weather? {
        get {
            guard cachedData == nil else { return cachedData }
            guard let data = savedDataManager.store.data(forKey: SavedDataManager.Keys.weather.rawValue) else { return nil }
            guard let weather = try? JSONDecoder.decoder.decode(Weather.self, from: data) else { return nil }
            cachedData = weather
            return weather
        }
        set {
            guard let data = try? JSONEncoder.encoder.encode(newValue) else { return }
            savedDataManager.store.set(data, forKey: SavedDataManager.Keys.weather.rawValue)
            cachedData = nil
            objectWillChange.send()
        }
    }

    func reset() {
        cachedData = nil
    }
}

The only real downside is that I need to call reset() if the iOS app updates the data, but the watch app needs to be informed. (I'm not sure if there's a better way to do this...)

Anyway, just wanted to toss that out as an alternative to a 5 second LRU cache. I'd say if we're caching by time, 1 second would be plenty, or ideally we could cache for the duration of a SwiftUI View being rendered, since I think that's the only place where this might be a common enough issue.