Personally, I appreciate you posting this link once, but seeing it this many times gets tedious.

Unfortunately it is hard to give an answer were all advocates of "Swift ARC performance" are able to read, thus urban myths keep being spread.

ARC makes sense given Objective-C compatibility, as otherwise a layer similar to RCW on .NET for dealing with COM/UWP would be needed.

And Objective-C only dropped its tracing GC, because it was too unstable while mixing GC enabled frameworks with classical ones, while making the compiler automatically call retain/release would provide better productivity without being unstable.

I understand the urge to reply in multiple places. I think it would be better to write up some more detailed reasoning, like you did here, and link to this from multiple subthreads. Better than just repeating the same ixy link with a new snide comment each time.

Makes sense.

> too unstable while mixing GC enabled frameworks with classical ones

Actually, you couldn't mix them. The GC simply never really worked properly.

True, however Apple's documentation suggested otherwise, that it was possible "with care".

But as you say, it never worked properly.

I think what you are referring to is "mixed mode" frameworks, which were able to work in both GC and RC environments. You had to do a bit of work to get that.

Which is similar but not quite the same thing. Mixing pure GC and pure RC frameworks was never possible. In fact, I think there were some flags and the (dynamic) linker would balk.

Which urban myth do you see being spread in this thread?

ARC outperforming modern tracing GCs.

Literally nobody here has said that.

I could collect statements about Swift compiler performance, how it removes retain/release calls, or how reference counting is so much better than tracing GC, but yeah lets live at here.