[mpweiher]

You don't have a link to the data because this is not true.

Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare.

Yes, I have measured.

One example is JSON and Swift codable, which is comically slow, see:

Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo

https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s.

I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.

[astrange]

This largely depends on how much of Swift<>ObjC bridging you'll hit, as such it'll get faster if more of Foundation is converted to Swift.

In particular Swift is more memory efficient than ObjC because there's less boxing overhead to small values. That should matter more than the overhead from more overflow checking.

[mpweiher]

> Swift<>ObjC bridging

This is another commonly held belief that doesn't hold up to actual measurements.

For an example, see part 2: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-...

All the pure Swift implementations are even slower than the bridged ones, and the bridged ones are slower than the most comically inefficient Objective-C one (using KVC, for example), which is slower than the reasonable Objective-C ones.

> In particular Swift is more memory efficient than ObjC ...

It's not.

> ... because there's less boxing overhead to small values

You would think, yes. I actually did think that as well. Because it really sounds plausible. So imagine my surprise when I measured some common cases for my book (Chapter 9) and it turned that even in the cases where I just knew™ that Swift would be faster, because of this very reason, it just wasn't.

> That should matter more than the overhead from more overflow checking.

Computers don't care what you think "should" be the case, and they cannot be argued into better performance due to plausible arguments and strongly held beliefs.

You need to measure what actually is the case.