Objective-C message call efficiency

Well the Objective-C vs. C++ thread reminded me of and issue I've always been curious about. In Objective-C telling the compiler what type of object you are sending the message to is supposed to increase the speed of the program right? (ie using myClass variables instead of id variables) Does anyone know what kind of speed benefits we are talking about? How about referring to a variable by a super type (ie animal instead of dog)?

I don't really know how Obj-C handles method calls, but I would doubt that it is the case. It's more probable that specifying the class as the type simply allows the compiler to do some additional type checking for you.

I don't think that's all there is to it. From what I've read, I too have been under the impression that the runtime environment deals with known types faster/better than id (unspecified) types. I hardly ever use id anyway though...

Final in Java could, at least theoretically, be used to speed things up (I don't know enough about the bytecode to say if it can help there, but it definitely can help in the JIT). ObjC is more dynamic than Java, so such optimizations are even less possible. +poseAsClass: is particularly difficult.

On 10.3 and below, the calls to objc_msgSend must go the normal route of a call to a function in a dynamically-linked library, which involves (at best) at least one additional jump than a regular function call.

Mac OS X 10.4 introduces the concept of the "commpage", which stores (processor-optimized) versions of common routines (memcpy, objc_msgSend, etc.). What "fast ObjC message dispatch" does is emit a call to the objc_msgSend on the commpage, which is at a fixed address, and therefore doesn't pay the penalty of a call into a dynamic library.

Incidentally, one of the benefits of the aglMacro/CGLMacro OpenGL optimizations is that they avoid the call into they dynamic library. (The other, probably more significant one is that they avoid looking up the current context).

OneSadCookie Wrote:Mac OS X 10.4 introduces the concept of the "commpage", which stores (processor-optimized) versions of common routines (memcpy, objc_msgSend, etc.). What "fast ObjC message dispatch" does is emit a call to the objc_msgSend on the commpage, which is at a fixed address, and therefore doesn't pay the penalty of a call into a dynamic library.