[klodolph]

Just to explain why Objective C code, in practice, is not especially fast:

You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time.

Swift makes it easier to eliminate things like dynamic dispatch while still keeping the safety. So it should be normal and expected that a rewrite from Objective C to Swift would result in a speedup (and increase in code size).

[mpweiher]

While this is what a lot of people believe, it happens to not be true.

For more details, see iOS and macOS Performance Tuning: Cocoa, Cocoa Touch, Objective-C, and Swift, Addison-Wesley

https://www.amazon.com/iOS-macOS-Performance-Tuning-Objectiv...

If you don't want to read a book, here is an example as a series of blog posts: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

[klodolph]

I read the blog post, but it just seems to provide a single example of a case where some particular piece of Objective C code was faster than the equivalent piece of code in Swift. Maybe there's something I'm missing here... what should I be looking for in these blog posts?

[dilap]

In practice would be what the resulting apps turn out like.

In my experience, old-school ObjC iOS and Mac apps generally tended to be quite snappy.

On the other hand, the new Swift hotness of Messages and Settings on macOS are noticably slower than what they're replacing.

Of course I haven't done a comprehensive inventory, but I certainly don't have the general impression of things getting faster with Swift. (Are there examples of this?)

My guess is any theoretical gains are generally swamped by the language culture of complex abstractions.

[klodolph]

Somebody rewrote an app in Swift -> the app is slower.

Somebody rewrote a library in Swift -> the library is faster.

There's a lot to talk about and unpack here. My experience is that people develop a different mindset when they do library development, because any code that they write will be code that they're forced to support for decades to come. You put bad code in an app and you can simply rip it out with the next revision, no questions asked. So you are much more likely to end up with questionable code in an app than in a library.

I'm also old enough to remember not only the same complaints when people were rewriting apps into Objective C (lots of early Mac OS X apps were Carbon, including Finder), but when the same complaints were made about rewrites from assembler into C. Every decade your computer has a hundred times more computing power and your code takes 10x as much footprint, so you come out ahead, on average. It's just that any given year you might come out behind.

[saagarjha]

Messages is largely an Objective-C codebase.

[dilap]

Ah, my bad, I just assumed the new version would be in Swift.

[saagarjha]

It’s the iOS codebase.