This chapter is from the book
This chapter is from the book
This chapter is from the book
Methods
Objective-C methods generally fall into two rough categories: lean and mean C data manipulation on one hand and high-level coordination using message sends on the other.
For the data-manipulation methods, all the usual tricks in the C repertoire apply: moving expensive operations out of loops (if there is no loop, how is the method taking time?), strength reduction, use of optimized primitives such as the built-in memory byte copy functions or libraries such as vDSP, and finding semantically equivalent but cheaper replacements. Fortunately, the compiler will help with most of this if optimization is turned on. In fact, instead computing the end-results of the loops, LLVM/clang managed to optimize away most of the simple loops from our benchmark programs unless we specifically stopped it.
In order to keep data manipulation methods lean and mean, it is important to design the messaging interface appropriately, for example, passing all the data required into the method in question, rather than having the method pull the data in from other sources.
High-level coordination methods should generally not be executed very often and therefore do not require much if any optimization. In fact, I’ve had excellent performance results even implementing such methods in interpreted scripting languages. A method triggering an animation lasting half a second, for example, will take less than 0.2% of available running time even if it takes a full millisecond to execute, which simply won’t be worth worrying about.
Pitfall: CoreFoundation
One of the recurring themes in this chapter has been leveraging C for speed and making careful tradeoffs between the “C” and the “Objective” parts of the language in order to get a balance between ease of use, performance, and decoupling and dynamicism that works for the project at hand.
However, it is possible to get this terribly wrong, as in the case of CoreFoundation. CoreFoundation actually throws out the fast and powerful bits of Objective-C (messaging, polymorphism, namespace handling) and manages to provide a cumbersome monomorphic interface to the slow bits (heap allocated objects). It then encourages the use of dictionaries, which are an order of magnitude slower still. The way CoreFoundation provides largely monomorphic interfaces to CoreFoundation objects that actually have varying internal implementations means that each of those functions, with few exceptions, has to check dynamically what representation is active and then run the appropriate code for that representation. You can see this in the OpenSource version of CoreFoundation available at http://opensource.apple.com/source/CF.
An Objective-C implementation leaves that task to the message dispatcher, meaning that both method implementations can be clean because they will only be called with their specific representation, also making it easier to provide a greater number of optimized representations.
While I’ve often heard words to the effect that “our code is fast because it just uses C and CoreFoundation and is therefore faster than it would be if it were to use Objective-C,” this appears to be a myth. I’ve never actually found this claim to be true in actual testing. In fact, in my testing, pure Objective-C equivalents to CoreFoundation objects are invariably faster than their CoreFoundation counterparts, and often markedly so. Sending the -intValue message shown in Example 3.17 is already 30% faster than calling the CoreFoundation CFGetIntValue() function, despite the message-passing overhead. Dropping down to C using IMP caching makes it over 3 times faster than the CoreFoundation equivalent.
The same observations were made and documented when CoreFoundation was first introduced, with users noticing significant slowdowns compared to the non-CoreFoundation OPENSTEP Foundation (apps twice as slow on machines that were supposed to be faster4 ). This obviously does not apply to the NSCF* classes that Apple’s Foundation currently uses; these cannot currently be faster than their CoreFoundation counterparts because they call down to CoreFoundation.