Performance of Automatic Equality Checks
March, 2024
This is an update to my previous article where I showed how you could compare objects in an automated way using the Objective-C runtime. At the end of it I asked:
It makes me wonder though, how would this compare to the compiler-generated
==
andhash(into:)
functions of a Swift class? 🤔
It was a throwaway comment to wrap up the article, but since then it’s been bugging me. So I just had to find out the answer!
The test candidates
For the performance showdown I created four versions of the same data model: a Swift struct, a Swift class and two Objective-C classes. Each is a reasonably large data structure with 24 properties, so we can really stress the different equality implementations.
1. Swift struct
First up is the Swift struct with automatic Hashable
conformance, which means the compiler will generate the ==
and hash(into:)
functions for us:
struct EqPerfStruct: Hashable {
var byte1: UInt8
var int1: Int
var arr1: [String]
var dbl1: Double
// plus the same types repeated 5 more times
}
2. Swift class
For the Swift class we have to manually implement the equality functions because the compiler does not generate these for classes:
final class EqPerfSwiftClass: Hashable {
var byte1: UInt8
var int1: Int
var arr1: [String]
var dbl1: Double
// plus the same types repeated 5 more times
static func == (lhs: EqPerfSwiftClass, rhs: EqPerfSwiftClass) -> Bool {
guard lhs.byte1 == rhs.byte1 else { return false }
guard lhs.int1 == rhs.int1 else { return false }
guard lhs.arr1 == rhs.arr1 else { return false }
guard lhs.dbl1 == rhs.dbl1 else { return false }
// test the remaining 20 properties...
return true
}
}
One interesting thing I learned: this is exactly how the Swift compiler generates the automatic
Equatable
conformance.
3. Objective-C class using manual equality
The first Objective-C class has a standard hand-coded isEqual
method:
@interface EqPerfObjCClassManual: NSObject
@property (nonatomic) uint8 byte1;
@property (nonatomic) NSInteger int1;
@property (nonatomic) NSArray *arr1;
@property (nonatomic) double dbl1;
// plus the same types repeated 5 more times
@end
@implementation EqPerfObjCClassManual
- (BOOL)isEqual:(id)object {
if (![object isKindOfClass:EqPerfObjCClassManual.class]) { return NO; }
EqPerfObjCClassManual *other = (EqPerfObjCClassManual *)object;
return self.byte1 == other.byte1
&& self.int1 == other.int1
&& [self.arr1 isEqualToArray:other.arr1]
&& self.dbl1 == other.dbl1
// test the remaining 20 properties...
}
@end
4. Objective-C class using automatic equality
Finally, we have an Objective-C class with an identical interface but using the automatic ivar-based equality from the previous article. This one is called EqPerfObjCClassAuto
.
The test setup
For each of the four candidates I measured the performance using XCTestCase.measure
. Since each equality check takes only a few nanoseconds, I called them 100,000 times per test run:
func testStructs() {
let s1 = EqPerfStruct(), s2 = EqPerfStruct()
measure {
for _ in 0..<100_000 {
_ = s1 == s2
}
}
}
I made sure that the tests were run in the Release configuration with diagnostics disabled.
Initial results
The performance tests produced an obvious winner:
Candidate | Notes | Time |
---|---|---|
Swift struct | Generated equality | 7 ms |
Swift class | Manual equality | 30 ms |
ObjC class | Manual equality | 33 ms |
ObjC class | Automatic equality | 24 ms |
The clear takeaway here is that the equality functions generated by the Swift compiler for structs are really fast and you should definitely take advantage of those whenever possible. I was surprised that the Swift and Objective-C classes are very comparable performance-wise, considering that the Swift class is using static dispatch versus dynamic dispatch for the ObjC class. The automated equality method is around 30-40% faster than the hand-coded one which lines up with my experience in production code.
But I wasn’t done yet, there were a few other variations I wanted to test...
Non-final Swift class
I was curious how much difference declaring the Swift class as final
made, so I made another version of it which was not marked as final
:
Candidate | Notes | Time |
---|---|---|
Swift class | Manual equality, final | 30 ms |
Swift class | Manual equality, non-final | 51 ms |
This actually looks a bit suspicious, even a non-final
Swift class shouldn’t be so much slower than the Objective-C equivalent 🤨
After checking the High-Performance Swift docs I noticed that “whole-module optimisation” is off by default even in Release builds. When WMO was enabled the Swift class tests got ridiculously fast (under 0.01ms) even with 1000x as many iterations! Clearly the call to the equality function was being optimised away, so I tweaked the tests to actually use the result of ==
instead of discarding it and finally got some reasonable-looking results with WMO enabled:
Candidate | Notes | Time |
---|---|---|
Swift class | Manual equality, final | 6 ms |
Swift class | Manual equality, non-final | 11 ms |
This looks much more impressive now, and the Swift class and struct are very comparable. The slight advantage to classes may be due to not having to copy around the large struct value.
Swift class with dynamic properties
What if we made the Swift class behave the same as the ObjC class? We can do this by adding the dynamic
keyword to each of the Swift properties, which forces them to be called with objc_msgSend
just like in Objective-C:
Candidate | Notes | Time |
---|---|---|
ObjC class | Manual equality | 33 ms |
Swift class | Manual equality, dynamic | 33 ms |
I found this quite interesting as it implies that all the performance benefits of Swift in this scenario are solely due to using static dispatch.
Direct ivar access in Objective-C
In the previous article we saw that while performing a lot of equality checks, the runtime itself can be a bottleneck because of all the message sending. So what if instead of accessing every property via the getter in our isEqual
method we used the ivar directly? Reading _byte1
instead of self.byte1
would save a call to objc_msgSend
each time. Our isEqual
method from above would look more like this:
return _byte1 == other->_byte1
&& _int1 == other->_int1
&& [_arr1 isEqualToArray:other->_arr1]
&& _dbl1 == other->_dbl1
// test the remaining 20 ivars...
Candidate | Notes | Time |
---|---|---|
ObjC class | Manual equality, using properties | 33 ms |
ObjC class | Manual equality, using ivars | 12 ms |
That is way faster! It’s now very similar to the performance of the non-final
Swift class, which makes sense because there is far less message sending going on.
Direct-dispatched Objective-C properties
Did you know that now we can even mark Objective-C methods and properties as direct
dispatch? It may be of limited usefulness since it makes your methods non-public and non-overridable, but I was curious to see what difference it makes to equality performance.
I created yet another test class and annotated it as having direct
members:
__attribute__((objc_direct_members))
@interface EqPerfObjCClassDirect : NSObject
Despite the article saying “You can’t annotate the primary class interface”, I found this actually worked fine, so maybe it’s been fixed since Mattt wrote that.
Using direct
properties certainly makes an improvement, but not quite as much as using ivars instead:
Candidate | Notes | Time |
---|---|---|
ObjC class | Manual equality, using properties | 33 ms |
ObjC class | Manual equality, using ivars | 12 ms |
ObjC class | Manual equality, direct properties | 21 ms |
Final results
Here are the performance results of all of the different variations:

These pretty much line up with my expectations: Swift is fast due to static dispatch and adding any indirection to that has a performance cost. It’s nice to see that Objective-C is very competitive with the equivalent Swift classes!
But wait, weren’t the automated equality methods supposed to be the fastest option for Objective-C? Well there may have been a couple of details I didn’t mention in that article.
Two more things
Even though automated equality was mainly about reducing boilerplate in the app I worked on, I used two additional shortcuts that made the equality checks significantly faster.
Fast bitwise comparison
Since classes are backed by structs, it’s possible to compare the backing structs of two objects as raw blocks of memory using memcmp
. This will only tell you if the objects are bitwise identical, so any object properties must contain the exact same pointers. It’s still a useful shortcut if you expect large objects to be equal a lot of the time.
There is one small wrinkle: we need to skip the isa
field at the start of each class because that is no longer a pointer and now contains housekeeping information instead. Given that, we can add this inside our isEqual
method:
// Skip the isa fields
Ptr selfAfterIsa = (__bridge void *)self + sizeof(Class);
Ptr otherAfterIsa = (__bridge void *)other + sizeof(Class);
size_t sizeWithoutIsa = class_getInstanceSize(self.class) - sizeof(Class);
// Compare as raw memory, returns 0 if identical
if (memcmp(selfAfterIsa, otherAfterIsa, sizeWithoutIsa) == 0) {
return YES;
}
// Otherwise continue with memberwise equality...
Using this shortcut in the performance tests results in a time of 7ms, but only when comparing equal objects of course. This is as fast as Swift structs!
Side note: it turns out this
memcmp
trick does not work on Swift structs because unlike ObjC objects they are not initialised to all zeroes. This means the padding between fields is usually different even with two equal structs.
Cached hash comparison
This second shortcut helps when the objects are unequal, but it does come with a big caveat: the objects must be immutable. In the app I worked on, this was used with classes which only had readonly properties and could not be changed after initialisation (think: Redux state or wrapped JSON payloads).
If your objects are immutable then you can cache their hash
values because they should never change. Since objects with different hash values must be unequal, we can quickly test those in isEqual
before we compare every property:
// Pre-check of cached hash values
if (self.hash != other.hash) {
return NO;
}
// Otherwise continue with memberwise equality...
Note that this doesn’t work the other way around; two unequal objects may have the same hash value.
This second shortcut resulted in a time of 6ms when comparing unequal immutable classes, which is also as fast as Swift structs.
Conclusion
Going back to the original question “how does my automated equality in ObjC hold up against Swift?” I have to say the answer is: amazingly well! I honestly didn’t expect it be just as fast as the generated ==
function of a Swift struct though.
It’ll be a shame to remove this automated equality during the migration away from Objective-C but I certainly don’t have to worry about the performance of the Swift replacement.
Any comments or questions about this post? ✉️ nick @ this domain.
— Nick Randall