Observer pattern is used for one-to-many communication. Subject-object automatically notifies its observers about given state change or an event. The pattern gives a possibility to seamlessly track changes in the state of the observed entity. For instance, given a numeric property, one would be notified whenever the stored value’s been changed.

What, how and what for

iOS developers are well familiar with delegation patterns, completion handlers etc., those are well-known approaches of how one object can communicate with other. Those are often used for propagation of particular events or as an indication of a finished task, rather than tracking changes on value/property level though. In some scenarios, it can be useful to observe changes of particular properties, so that whenever one occurs given object can immediately be notified and react to the change accordingly. Having to setup delegation methods or callback blocks would mean a lot of boilerplate code. The important bit here is that this is a one-to-one communication. Sometimes more than one object might need to track changes, in such case the delegation pattern is not sufficient, as it allows only for communication between a pair of objects.

The goal of this article is to compare different approaches, benchmark their performance and investigate eventual differences. Before proceeding, I would like to emphasise that the benchmarks are not a general indication of how performant specific approaches are. The article covers aspects of property observation. Various 3rd party libraries offer much more functionality than that, therefore conducted comparison is not an indication of their overall performance.

Observation methods

In Swift, iOS development there are two standard techniques, which allow to easily use the pattern - KVO and NotificationCenter. The former is unfortunately available only on Apple platforms. There are other 3rd party Swift-native frameworks though, like RxSwift, ReactiveSwift, which rely on concepts of reactive programming.

KVO

One of the techniques is Key-Value Observation (KVO). As per Apple’s developers website:

Key-value observing is a mechanism that allows objects to be notified of changes to specified properties of other objects.

KVO is dependant on Objective-C runtime, so the observed object needs to be a subclass of NSObject. To make stored properties KVO compliant the @objc attribute and dynamic decorator must be used, like that:

1
2
3
4

class KVOSource: NSObject, StateProtocol {

    @objc dynamic var duration: TimeInterval = 0
}

Tip: Working with classes whose properties must be exposed to Objective-C runtime it might be easier to use @objcMembers, to avoid having to specify @objc for each of the properties.

1

@objcMembers class KVOSource: NSObject { }

The observer can then setup the observation as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

class MyOldObserver: NSObject {
 
    let source: KVOSource

    func setupObservation() {
        source.addObserver(
            self, 
            forKeyPath: "duration", 
            context: &kObservationContext
        )
    }
    
    deinit {
        source.removeObserver(self, forKeyPath: "duration")
    } 
}

To be able to respond to changes the observer must override observeValue(forKeyPath:of:change:context:) method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

class MyOldObserver: NSObject {

    @objc override func observeValue(
        forKeyPath keyPath: String?, 
        of object: Any?, 
        change: [NSKeyValueChangeKey : Any]?, 
        context: UnsafeMutableRawPointer?
    ) {
        guard context == &kObservationContext else {
            super.observeValue(
                forKeyPath: keyPath, 
                of: object, 
                change: change, 
                context: context
            )
            return
        } 
    }
    
    // check `keyPath` and react to changes
}

In older versions of Swift, observers also needed to be subclasses of the NSObject type, but since version 3.2 it is possible to use key path expression to subscribe for changes and use observation tokens. Not only key path expressions are more safe, as there’s no longer need to use raw strings, but also there’s no need to explicitly remove observation as the token object will automatically stop observation on deinitialization. There’s also no need to override the observeValue method, as the new KVO API uses blocks.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class MyNewObserver {

    let source: KVOSource
    var token: NSKeyValueObservation?
    
    func setupObservation() {
        token = source.observe(\.duration) { object, change in
            ...
        }
    } 
}

NotificationCenter

NotificationCenter is yet another mechanism known back from Objective-C, defined in Foundation. Each of the notifications that can be broadcasted needs to have its unique name, therefore, has to be explicitly defined and sent. It was not built in mind for property observation like KVO was. It is therefore similar to the delegation pattern, with the difference being that it allows for many-to-many observation.

NotificationCenter is using the singleton pattern, you can access its common instance from the default static property. There’s an API for subscribing using the Objective-C selectors, but there’s also a variation of it with a block based callback.

1
2
3
4
5
6

NotificationCenter.default.addObserver(
    self,
    selector: #selector(movedToBackground),
    name: .UIApplicationDidEnterBackground, 
    object: nil
)

Or using blocks

1
2
3
4
5
6
7

NotificationCenter.default.addObserver(
    forName: .UIApplicationDidEnterBackground, 
    object: nil, 
    queue: nil
) { notification in

}

Similarly to KVO, the block based method returns a token object that later can be unregistered from observation using NotificationCenter.default.removeObserver(_:). Either passing the observer when using selectors API, or the returned token-like object from the block variation.

The selector approach has one nice benefit - if you’re targeting iOS 9+, as there’s no need to manually deregister the observer object, with blocks you still have to do so.

Benchmark

The benchmark is about observing four distinct properties and incrementing observation counter upon each change event. Performance determinant was how long it took to generate m change events for each of the properties for given n observers, that were listening for changes.

In the benchmark the following observation techniques were tested:

• Legacy KVO
• Modern block based KVO
• Legacy KVO implemented in Objective-C bridged to Swift
• NotificationCenter
• RxSwift

Initially I was also going to compare another reactive programming library - ReactiveSwift, but its performance was on pair with RxSwift so I decided not to include those results.

Implementation

To implement all different kinds of observation techniques and benchmark them I’ve defined following protocols:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

protocol Producer {

    associatedtype Storage: AnyObject
    var storage: Storage { get }

    func updateProperties(_ i: Int)
    init()
}

protocol Consumer: class {

    associatedtype AssociatedProducer: Producer

    init(_ storage: AssociatedProducer.Storage)
    var counter: AtomicInt { get }
}

For each of the methods there is one Producer conforming type defined, that has its associated Storage type. The Storage is where the properties are defined. After calling updateProperties Producer is supposed to update properties of its Storage. Consumer on the other hand is the object observing for changes, so in one test there were always n instances of consumers for a given technique. Those objects are initialised with the Storage from its associated Producer type. During (de)initialisation Consumers (de)attach themselves for tracking changes in the storage.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

// 1. First we need to define the storage object
class KVOStorage: NSObject {

    @objc public dynamic var foo: TimeInterval = 0
    @objc public dynamic var bar: TimeInterval = 0
    @objc public dynamic var baz: String = ""
    @objc public dynamic var qux: String = ""
}

// 2. Next is the `Producer` that will update the storage
class KVOProducer: Producer {

    let storage = KVOStorage()

    required init() {}

    func updateProperties(_ i: Int) {
        storage.foo = Double(i)
        storage.bar = Double(i)
        storage.baz = "foo \(i)"
        storage.qux = "bar \(i)"
    }
}

// 3. Last thing is the `Consumer` - here the modern block based variation
class ModernKVOConsumer: Consumer {

    typealias AssociatedProducer = KVOProducer

    private var observers: [NSKeyValueObservation] = []
    private let storage: KVOStorage
    var counter = AtomicInt()

    private func observe<T>(path: KeyPath<KVOStorage, T>) {
        let kvo = storage.observe(
            path,
            options: [.initial]
        ) { [weak self] val, _ in
            var _val = val
            self?.sink(&_val)
        }

        observers.append(kvo)
    }

    required init(_ storage: KVOStorage) {
        self.storage = storage

        self.observe(path: \.foo)
        self.observe(path: \.bar)
        self.observe(path: \.baz)
        self.observe(path: \.qux)
    }

    @inline(never)
    private func sink<T>(_ val: inout T) {
        counter.increment()
    }
}

All the source code for the benchmark is open sourced and available at ¹.

Results

First conducted benchmark was a test of duration and complexity for each of the observation techniques. In the test there was a fixed amount of 10 consumer objects listening for the events.
m is a number of times updateProperties(i:) method on Producer ’s been called.

In the second test I wanted to check whether varying amount of observing objects would have an impact on any of the observation techniques. In this test the number of updateProperties(i:) method calls was fixed to 1_000.

Clearly, each of the techniques has a linear time complexity. The number of objects observing for changes also has a linear impact on observation performance. The KVO techniques implemented in Swift, whether the legacy one or the modern one based on blocks are significantly slower. Naturally, there would be some difference as KVO is an Objective-C native solution, so there’s a need for communication between Swift and Objective-C runtimes, but the difference is much more than I anticipated. Legacy KVO in Swift is approximately 6x slower than in Objective-C and modern KVO is 10x slower! RxSwift turns out to be the winner and shows the performance benefits of a native Swift solution.

I’d like to highlight once again, that this is not an actual indication of general RxSwift performance. Here in the test we’re only using it for observation. As one starts to use more Rx operators it’d of course have higher performance impact than doing it directly in methods.

Environment:

• Xcode 10.0 Beta 6 (Swift 4.2)
• macOS 10.14 Beta 8 (18A336e)
• iMac 5K 2017, 4.2 GHz Intel i7

KVO performance

(Lack of) KVO performance in Swift is quite surprising. Not only it is significantly slower compared to native Objective-C, but the new block based API itself has a significant impact.

To investigate the cause of those differences I’ve run the benchmark and analysed its course in the Instruments using the Time Profiler.

Legacy KVO

The point where KVO enters is the _NSSetDoubleValueAndNotify, there’s also another corresponding call _NSSetObjectValueAndNotify when the String properties are being set. Around 65% of time spent in those function is consumed by call to Dictionary._unconditionallyBridgeFromObjectiveC. As the KVO is a native Objective-C mechanism, the observeValue that we override in our class takes a change argument. The argument in Objective-C is a NSDictionary<NSKeyValueChangeKey,id>, and in Swift we receive Dictionary<NSKeyValueChangeKey: Any>. The transition from Objective-C to Swift type seems to have quite an impact.

Block KVO

With the block based KVO API on the other hand, there seems to be an additional impact coming from multiple dynamic type castings and type bridging for NSString -> String.

Code peak

In both cases it seems that parts that have crucial performance impact are defined in the libswiftFoundation library, luckily it is part of the Swift open source project, so we can actually see what’s happening in those methods. ²

As for the _unconditionallyBridgeFromObjectiveC (or _forceBridgeFromObjectiveC) call, we can find it in the Dictionary.swift.The function works as a force unwrap and calls to sister function _conditionallyBridgeFromObjectiveC. Both the functions use the _ to indicate implementation detail but are defined as public so it’s possible to use them directly. Looking at the implementation it turns out that function has O(n) complexity, as whether the source is NSDictionary or CFDictionary the function iterates over each of the Dictionary key-value pairs and attempts to cast them to Swift types.

The block API extension is a part of Foundation library, but contrary to the Objective-C bridge is defined in the main Swift³ repository NSObject.swift. To workaround some bug, as indicated by code comments, the core NSKeyValueObservation token object is using swizzled _swizzle_me_observeValue method instead of implementing it through overriding.
Using swizzling has one extra benefit, method signature can be changed to directly use native Objective-C types instead.

1
2
3

observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?)

_swizzle_me_observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSString : Any]?, context: UnsafeMutableRawPointer?)

This allows to skip the mapping between NSKeyValueChangeKey and raw NSString.

Interestingly in the swizzled method, there’s quite a lot of NSString -> String bridge traffic whilst all strings are referenced directly as NSStrings, e.g. change[NSKeyValueChangeKey.newKey.rawValue as NSString]. The method also in its signature directly takes NSString based change dictionary.
In order to investigate this method body in instruments, we could for once compile Swift Standard Library. The much simpler solution though is just to copy the source, rename the classes and manually setup observation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

class Foo: NSObject {

    @objc dynamic var bar: String = ""
}

let foo = Foo()
var c = 0
let ob = DMCKeyValueObservation(
    object: foo, 
    keyPath: \Foo.bar
) { _, change in
    c += 1
}
ob.start([])

for _ in 0 ..< 100_000 {
    foo.bar = "foo_bar"
}

print(c)

Running this code within the same module gives more detailed information. Now it is clearly visible that the cause of NSString -> String is indeed the NSKeyValueChangeKey:

String optimisation

Within the _makeCocoaStringGuts when referencing the NSKeyValueChangeKey a string copy is made through CFStringCreateCopy, in order to create a temporal String object. That’s a missed optimisation opportunity because the keys are directly referenced, thus never mutated. Moreover, those are static text values that can’t ever change.
Swift doesn’t define explicit types for non-mutable objects, instead, value types are used. Apparently, something is triggering copy-on-write mechanism. Better Objective-C interoperability could help to avoid redundant copies.
To see possible improvement of such optimisation, a matching change key structure can be defined directly in Swift:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

struct DMCKeyValueChangeKey: RawRepresentable {

    let rawValue: NSString

    static let newKey = DMCKeyValueChangeKey(rawValue: NSKeyValueChangeKey.newKey.rawValue as NSString)
    static let oldKey = DMCKeyValueChangeKey(rawValue: NSKeyValueChangeKey.oldKey.rawValue as NSString)
    static let indexesKey = DMCKeyValueChangeKey(rawValue: NSKeyValueChangeKey.indexesKey.rawValue as NSString)
    static let notificationIsPriorKey = DMCKeyValueChangeKey(rawValue: NSKeyValueChangeKey.notificationIsPriorKey.rawValue as NSString)
    static let kindKey = DMCKeyValueChangeKey(rawValue: NSKeyValueChangeKey.kindKey.rawValue as NSString)
}

That’s ~24ms (x1.17 speed up) less in this case. This on its own is not such a significant gain, but various aspects stack up together and result in significant performance difference.

Dictionary optimisation

The fact that this method is overridden through swizzling allows for yet another optimisation. In the compiler implementation type of the change argument is [NSString : Any]?, which does not differ much from a raw NSDictionary. Therefore NSDictionary can be used directly, thanks to which there’s no need to bridge Objective-C type to the native Swift dictionary.
Such change results in ~4x speed up.

Final swizzled method would then look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

@objc func _swizzle_me_observeValue(forKeyPath keyPath: String?, of object: Any?, change: NSDictionary?, context: UnsafeMutableRawPointer?) {
    guard let ourObject = self.object, object as? NSObject == ourObject, let change = change else { return }

    let rawKind:UInt = change[DMCKeyValueChangeKey.kindKey.rawValue] as! UInt
    let kind = NSKeyValueChange(rawValue: rawKind)!
    let notification = DMCKeyValueObservedChange(
        kind: kind,
        newValue: change[DMCKeyValueChangeKey.newKey.rawValue],
        oldValue: change[DMCKeyValueChangeKey.oldKey.rawValue],
        indexes: change[DMCKeyValueChangeKey.indexesKey.rawValue] as! IndexSet?,
        isPrior: change[DMCKeyValueChangeKey.notificationIsPriorKey.rawValue] as? Bool ?? false
    )

    callback(ourObject, notification)
}

Conclusion

Both the optimisations contributed to overall ~x4.68 performance gain (304 ms -> 65 ms). It’s highly possible that there are other, maybe lower level, optimisations that could improve KVO performance.
Examples like this show that there’s still a lot of place for improvements in the Swift compiler.
I can imagine this causing a lot of confusion for new language programmers, who do not have a good understanding of Objective-C and the need of type bridging between the two.

References

• Key-Value Observing
• RxSwift
• NotificationCenter

Thanks for reading! If you’ve got any questions, comments or general feedback please feel free to reach out. (You can find all of the social links at the bottom of the page).