4 ms·
What's the point opining on which is faster when you don't even know what ARC stands for, and thus presumably not the first thing about it? Apple's frameworks
by 1over137 3y ago
What's the point opining on which is faster when you don't even know what ARC stands for, and thus presumably not the first thing about it?
Apple's frameworks used GC before, and they switched to ARC.
- kaba0 3y agoARC can stand for multiple things and is more of a marketing name here, than anything. The relevant garbage collector algorithm is called reference counting - and depending on whether it is single-threaded or have to do it over multiple threads, it can have quite a big overhead. Also, ObjC was also ref counted AFAIK before.
- koito17 3y agoWhat Apple calls "ARC", the rest of the word simply calls "RC". Unlike in Objective-C, the vast majority of RC implementations do not need the developer to modify refcounts by hand. It was already "automatic", so to speak. Moreover, ARC itself indeed modifies refcounts atomically. If it didn't, you would not be able to reliably determine the liveness of an object shared between threads. Now ask yourself whether atomically updating dozens of integers is faster than flipping a bit across a table of pointers.
- pjmlp 3y agoBasically Apple turned Objective-C's GC failure to deal with C semantics, picked COM's approach to smart pointers, and made a market message out of it into ARC, for people that never dealt with this kind of stuff before. Like in many things where "Apple did it first".
- pjmlp 3y agoYes, everyone that points that out usually has no idea that Objective-C GC failed due to C's semantics making it quite prone to crashes, and that automating Cocoa's retain/release calls was a much more easier and safer approach than making C code work in a sensible way beyond what a conservative tracing GC will ever be able to offer, while dealing with C pointers all over the place.