Some fans do measure, and know the difference from marketing and reality in regards to tracing GC versus reference counting marketing material.

https://github.com/ixy-languages/ixy-languages

Wallclock time isn't the only performance metric to care about. ObjC had a GC in the past and lost it in favor of ARC for a reason; it's a poor fit for iPhone-sized devices.

That was the marketing reason, the official reason was that fitting a GC into a language with C memory model wasn't never going to work, and there were plenty of crashes and memory corruptions coming out of that.

So they made the only sensible decision, and just like Microsoft did with COM, they added support to the Objective-C compiler to automate retain/release messages in OS X Frameworks.

Naturally being Apple, that pivot had to be sold in a way that the reason was being of RC being better and not because of the technical failure to have a tracing GC in Objective-C , while remaining compatible with C memory model.

Apparently, moving the GC document with all its caveats regarding possible programming issues, out of search index also helps to keep the story as well.

https://developer.apple.com/library/archive/documentation/Co...

No, the performance issues are real. GC programs have more page demand and higher peak memory use, which is specifically what the iOS memory model (jetsam and memory compression) can't deal with well. They can have some wins due to compacting.

There is of course a GC language on iOS (JavaScript) but expensive webpages get killed quickly.

And yet Microsoft was able to do very good phones with GC languages with very good performance for 200 euros, maybe Apple should talk to their runtime engineers.

Wasn't most of the system stack in C++ since it was shared with either Windows or Nokia? Either way, they went out of business, so we can't tell if they can support a phone 5 years back with new OS features.

The worst case performance is very bad though. I have done some playing around with pushing Swift in terms of performance, and it's very hard because of ARC.

Code in the fastpath must not generate substantial garbage whether using ARC or a gc. That's just a coding error.

It's not about garbage creation, is about reference cost. With ARC, you pay a penalty every time you pass a reference type, not only for memory churn. You can avoid this using value types, but this often results in a lot of unnecessary copying.

It's not unavoidable, but Swift doesn't give good tools for avoiding ARC-based performance cliffs, so it takes a lot of profiling and effort compared to other languages.

It's ok to generate garbage if it goes away immediately; that's essentially a stack allocation. Performance problems come up when you have a mix of lifetimes. (that slows GCs down and causes heap fragmentation outside copying GCs)