Yes, if you were doing a quick sort and each op required a msgsend it'd be a factor. But you'd have to be crazy to write code like that. This is why there are a lot of C apis that Apple has written that you call and bridge with ObjC.

With Swift you can't do that. You have to wrap the calls and generate bridge headers. What a pain.

Are you surprised that a language that's officially 2 days old has worse support than a language that they've been using for the last maybe 25 years?

Do you have an application where message sending is a performance bottleneck?

Whether it is a bottleneck or not is a different question.

I think mpweiher's point was that in normal Objective-C applications, the fact that message sending is slow is irrelevant. Yes, it is slower than a C function call, but it's rare that it is an issue in real code. When it was a problem before, in something unusual like your article's heavy tree traversal, you'd inline the code or drop down to C. But that was fairly rare. Apple has also improved objc_msgsend within the past few years.

My wild guess is that with Swift, Apple is trying to get a more lightweight language not due to performance issues but due to battery consumption. I think that around 40% of CPU time of your average obj-c app is spent in objc_msgSend. That is potentially a lot of power essentially wasted.