[gok]

Generally impractical for real-world ObjC, which has around 100,000 method names.

Apple ObjC used to have a simplified version of this which used a vtable for the most frequent 16 selectors. It wasn't considered profitable after sufficient optimizations on the hash-table based method cache.

[vidarh]

Apart from sounding absolutely crazy (not doubting you; I've seen how verbose Objective-C can get), that sounds like the method names almost certainly will consists of many sets of names that are likely only used by small sets of classes, in which case the extra indirection in Franz' approach should work just fine, and not require any caching.

What I saw when looking at this before choosing to go that route years ago is that most dynamic language implementations seems to have just rejected vtable based approaches out of hand or never considered them at all because it's become seen as a "write once" approach unsuitable for updates and the default assumption has become that a complex lookup is needed.

It's been a few years since I looked, but last time I looked Franz' paper was the only one I found that investigated dynamic changes to objects at runtime using a vtable-like approach at all, and ironically he did so with a statically typed language... It seems like a curious blindness to me - maybe it genuinely is unsuitable for Objective-C, but most dynamic dispatch mechanisms I've looked at have been in environments where the number of names being looked up tends to be too small for even Franz' approach to be necessary.

(For Ruby the method name count tends to remain quite small, to the point where Franz' approach doesn't seem worth the cost of that extra indirection most of the time)