4 ms·

I think putting it that way exaggerates the differences a bit. The message doesn't really have to be "interpreted" in any meaningful way AFAIK. A message consis

by chc 11y ago

I think putting it that way exaggerates the differences a bit. The message doesn't really have to be "interpreted" in any meaningful way AFAIK. A message consists of a selector (essentially a method name) and a receiver, then whatever other arguments the method will take. The runtime looks up the selector in the receiver's method table, much like with C++ virtual methods, and then jumps to the implementation it finds. There is a little more fanciness (some method caching, and support for nil receivers), but I don't feel like it's hugely dissimilar from virtual methods. For anyone interested, here's a good analysis of Objective-C's message dispatch machinery: http://blog.zhengdong.me/2013/07/18/a-look-under-the-hood-of-objc-msgsend http://blog.zhengdong.me/2013/07/18/a-look-under-the-hood-of...

pcwalton 11y ago
The vtable is a flat structure with known layout in C++. In Objective-C, it's a hash table (with precomputed hashes and lots of other tricks—but it's still fundamentally a hash table). There's a big difference between the two.
- chc 11y ago
  There's a big difference between the data structures, yes, but the basic logic for message sends is still pretty similar. They both boil down to a simple lookup in a data structure and a jump. Would you really characterize the difference between a vtable and a hash table as "you actually pass a message, that first must be interpreted" in the case of a hash table?
  - fleitz 11y ago
    I think the biggest issue is that in a vtable you jump directly to the method by index, and with objc_msgsend it looks up a string in a hash table. Mostly the difference is ints vs. strings in my opinion. As well in C++ if you don't mark your method virtual you can bypass all the vtable crap. I love ObjC but method resolution is far more expensive than in C++, especially non-virtual methods.
    - astrange 11y ago
      Method selectors in Obj-C don't have to be strings, as long as you can turn a string into one occasionally. You do still need to do a hash lookup to get the method implementation, since the selector table changes at runtime and objects have to safely respond to unhandled selectors and all that.
      - fleitz 11y ago
        I meant string as in char* not NSString, selectors specifically the SEL datatype are strings They certainly don't have to be, however, they are. SEL selector = @selector(applicationDidBecomeActive:); printf("%s",(char*)(void*)selector); // Prints applicationDidBecomeActive:

by chc 11y ago

pcwalton 11y ago

The vtable is a flat structure with known layout in C++. In Objective-C, it's a hash table (with precomputed hashes and lots of other tricks—but it's still fundamentally a hash table). There's a big difference between the two.

chc 11y ago
There's a big difference between the data structures, yes, but the basic logic for message sends is still pretty similar. They both boil down to a simple lookup in a data structure and a jump. Would you really characterize the difference between a vtable and a hash table as "you actually pass a message, that first must be interpreted" in the case of a hash table?
- fleitz 11y ago
  I think the biggest issue is that in a vtable you jump directly to the method by index, and with objc_msgsend it looks up a string in a hash table. Mostly the difference is ints vs. strings in my opinion. As well in C++ if you don't mark your method virtual you can bypass all the vtable crap. I love ObjC but method resolution is far more expensive than in C++, especially non-virtual methods.
  - astrange 11y ago
    Method selectors in Obj-C don't have to be strings, as long as you can turn a string into one occasionally. You do still need to do a hash lookup to get the method implementation, since the selector table changes at runtime and objects have to safely respond to unhandled selectors and all that.
    - fleitz 11y ago
      I meant string as in char* not NSString, selectors specifically the SEL datatype are strings They certainly don't have to be, however, they are. SEL selector = @selector(applicationDidBecomeActive:); printf("%s",(char*)(void*)selector); // Prints applicationDidBecomeActive: