2 ms·

Sending a message is indeed equivalent to calling a function, specifically the function objc_msgSend (or one of its variants, depending on return type). It's a

• js2 16y ago
  In the normal case it's still very fast http://www.friday.com/bbum/2009/12/18/objc_msgsend-tour-part-3-the-fast-path/ http://www.friday.com/bbum/2009/12/18/objc_msgsend-tour-part...
  • othermaciej 16y ago
    My day job is working on a mixed C++/Objective-C project (Safari). My statement that ObjC method calls are slow is based on staring at a lot of profiles and poking into the assembly. If you study the page you linked, you can see that even the fast path results in four serialized load instructions: 1) Load class pointer from object movq (%rdi),%r11 2) Load cache pointer from class movq 0x10(%r11),%r8 3) Load cache entry (IMP) from cache movq 0x10(%r8,%rcx),%r11 4) Load function pointer from IMP movq 0x10(%r11),%r11 Notice that each of these loads reads into a register which is then treated as an address by the next load. This does a great job of totally stalling your pipeline while you wait for memory reads. I've been staring at this same grim pattern in the profiler since the days of PowerPC. C++ virtual function calls are doubly-indirect in the worst case (read vtable pointer from object, read function pointer from vtable). And because it's emitted at the call site and not hidden in a function, the compiler can often reduce it down to singly indirect or even direct link it as a static call, if it can prove the exact type. Objective-C is not as bad as some say, but if your code is highly optimized, method call overhead can become a bottleneck.
    • js2 16y ago
      Nice reply, thank you.