Performance Comparisons of Common Operations, 2016 Edition
Still, the speed of
objc_msgSendcontinues to astound me. Considering that it performs a full hash table lookup followed by an indirect jump to the result, the fact that it runs in 2.6 nanoseconds is amazing. That’s about 9 CPU cycles. In the 10.5 days it was a dozen or more, so we’ve seen a nice improvement. To turn this number upside down, if you did nothing but Objective-C message sends, you could do about 400 million of them per second on this computer.[…]
It appears to have slowed down since 10.5, with an
NSInvocationcall taking about twice as much time in this test compared to the old one, even though this test is running on faster hardware.A retain and release pair take about 23 nanoseconds together. Modifying an object’s reference count must be thread safe, so it requires an atomic operation which is relatively expensive when we’re down at the nanosecond level counting individual CPU cycles.
[…]
In the old test, creating and destroying an autorelease pool took well over 300ns. Here, it shows up at 25ns.
[…]
Objective-C object creation also got a nice speedup, from almost 300ns to about 100ns. Obviously, the typical app creates and destroys a lot of Objective-C objects, so this is really useful. On the flip side, consider that you can send an existing object about 40 messages in the same amount of time it takes to create and destroy a new object, so it’s still a significantly more expensive operation, especially considering that most objects will take more time to create and destroy than a simple
NSObjectinstance does.
