views:

1419

answers:

3

I am just staring to play around with Objective C (writing toy iPhone apps) and I am curious about the underlying mechanism used to dispatch messages. I have a good understanding of how virtual functions in C++ are generally implemented and what the costs are relative to a static or non-virtual method call, but I don't have any background with Obj-C to know how messages are sent. Browsing around I found this loose benchmark and it mentions IMP cached messages being faster than virtual function calls, which are in turn faster than a standard message send.

I am not trying to optimize anything, just get deeper understanding of how exactly the messages get dispatched.

  • How are Obj-C messages dispatched?
  • How do Instance Method Pointers get cached and can you (in general) tell by reading the code if a message will get cached?
  • Are class methods essentially the same as a C function (or static class method in C++), or is there something more to them?

I know some of these questions may be 'implementation dependent' but there is only one implementation that really counts.

+3  A: 

Mike Ash has a great blog that answers this type of question:

Objective-C Messaging.

Terry Wilcox
It looks like I am going to have to browse Mike's blog some more
Dolphin
+10  A: 

How are Obj-C messages dispatched?

Objective-C messages are dispatched using the runtime's objc_msgSend() function. Shown in the Apple docs, the function takes at least 2 arguments:

  1. The receiving object
  2. The selector of the message
  3. [A variable list of arguments to the message being sent.]

Instances of a class have an isa pointer, which is a pointer to their class object. The selectors of methods in each object are stored in a "table" in the class object, and the objc_msgSend() function follows the isa pointer to the class object, to the find this table, and checks whether the method is in the table for the class. If it cannot find it, it looks for the method in the table of the class's superclass. If not found, it continues up the object tree, until it either finds the method or gets to the root object (NSObject). At this point, an exception is thrown.

How do Instance Method Pointers get cached and can you (in general) tell by reading the code if a message will get cached?

From Apple's Objective-C runtime guide on Messaging:

To speed the messaging process, the runtime system caches the selectors and addresses of methods as they are used. There’s a separate cache for each class, and it can contain selectors for inherited methods as well as for methods defined in the class. Before searching the dispatch tables, the messaging routine first checks the cache of the receiving object’s class (on the theory that a method that was used once may likely be used again). If the method selector is in the cache, messaging is only slightly slower than a function call. Once a program has been running long enough to “warm up” its caches, almost all the messages it sends find a cached method. Caches grow dynamically to accommodate new messages as the program runs.

As stated, caching starts to occur once the program is running, and after the program has been running long enough, most of the method calls will run through the cached method. As it also says, the caching occurs as the methods are used, so a message is only cached when it is used.

Are class methods essentially the same as a C function (or static class method in C++), or is there something more to them?

Class objects handle method despatch in a similar manner to that of instances of classes. Each class object has an object that stores its own class methods, in an object called a metaclass. The class object has its own isa pointer to its metaclass object, which in turn has super metaclass objects, which it can inherit class objects from. Method dispatch to class methods is as so:

  1. The dispatch system follows the class object's isa pointer to the metaclass object
  2. The metaclass object's method table is searched for the class method.
  3. If not found, the search continues to the metaclass object's superclass, where the search continues.
  4. This process repeats until either the method is found, or until it gets to the root metaclass, and an exception is thrown.
Perspx
Excellent explanation. I find that understanding the dynamic dispatch system and how selectors are involved also explains rather well why method names must be unique, and Objective-C doesn't support overloaded methods in the same way Java and C++ do. Because the selector is cached as an integer, any method with the same name would map to the same selector. For better or for worse, it does force programmers to think more about properly naming methods.
Quinn Taylor
If you want to go deep... http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/
bbum
+2  A: 

I also wrote an instruction by instruction guide to objc_msgSend() on x86_64 on my weblog, if anyone wants to dive deep:

http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/

bbum