Hacker News Reader

Comment by icodestuff | Hacker News Reader

There are a number (16?) of vtable lookup-based message-sends for some of the common selectors, but in general, this is the fast path.

View on HN

The vtable-based dispatch (described in detail at http://www.sealiesoftware.com/blog/archive/2011/06/17/objc_e...) is no longer in use.

You know, when I tell people that Obj-C's message dispatch makes it a bit trickier to do a lot of the optimizations you find in C++ compilers, they always look at me like I'm crazy, but this seems like very clear evidence of this...

Why would they think you're crazy? It should be quite obvious that an Objective-C compiler simply cannot optimize across the message send boundary in any way, while a C++ compiler often can optimize across method calls.

Because despite pointing out exactly why I thought it was true and explaining Obj-C's various dispatch optimization tricks and how they still left an optimizing compiler/runtime with a far greater challenge, the response was generally, "you have no idea what you are talking about".

Thanks to Dunning-Kruger, it's quite difficult to be sure if they just can't be bothered to explain what I don't understand (maybe performance differences arise elsewhere... maybe there were far more sophisticated tricks in the modern message dispatch code than I'd come to understand... though it seemed unlikely they'd be so significant) or its the other way around.

Empirical evidence would seem to point strongly in my favour, but you'd think that'd give people some pause before making such statements.

Unfortunately, the nature of Objective-C as an Apple-centric language means a lot of people like it because Apple says they're supposed to, and don't take criticism of it well.

objc_msgSend is pretty amazingly fast, and is not usually a bottleneck in code, but the inability to do things like inline method calls when the target is known at compile time is a downer.

Any idea why it's no longer in use? The memory argument against vtables seems spurious - I'm using vtables everywhere for my in-progress Ruby compiler (with the intent of allowing an arbitrary cut-off on the vtables and spilling the excess messages into hash tables at some point), and as far as I've seen, it takes some pretty pathological cases (e.g. an app with an unusually huge amount of classes and methods that consists of little actual code, yet relatively small number of actual object instances allocated) before the memory waste for sparse vtables start becoming anything remotely significant relative to an applications other memory usage or code size.

Reply on news.ycombinator.com