[can16358p]

The performance "optimizations" are all about eliminating the bridge between ObjC and Swift.

I'd love to see a comparison of how the functions work within their own realm, e.g.:

- Speed of a date function in pure ObjC, tested in ObjC realm with no Swift bridge

- Speed of the same date function in pure Swift, tested in Swift realm with no ObjC bridge.

Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.

[lapcat]

> Otherwise, introducing an extra bridge with the language, then getting rid of it isn't a performance improvement, it's getting back to the baseline.

This is a strange comment, because Swift would have been Dead On Arrival in 2014 without that Objective-C bridging, an Apple-created language that doesn't work with Apple application frameworks.

[can16358p]

Perhaps I articulated incorrectly.

The bridge should have obviously existed (and should still exist for a very long foreseeable future if not forever). I was refering to having a benchmark with and without bridge and telling Swift is faster is a bit off, as that performance decrease was what Swift had to bring in the first place.

[lapcat]

Do you mean as some kind of Swift vs. Objective-C argument?

I don't think Apple is interested in having that argument in 2023. There's no point. Swift has won the "language war", politically within Apple and in developer mindshare outside Apple. (I say this as someone who continues to write Objective-C.)

[can16358p]

Nope, Swift clearly won (which was created by Apple themselves to replace ObjC in most places if not all eventually).

I think the metrics in their current form don't really mean much if it's only measuring the performance "gain" by getting rid of the ObjC/Swift bridge.