> On Jul 12, 2017, at 11:24 AM, Jens Alfke <j...@mooseyard.com> wrote: > >> On Jul 12, 2017, at 10:38 AM, Charles Srstka <cocoa...@charlessoft.com> >> wrote: >> >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the object’s lifetime is that non-ARC code may be calling >> the method. In an all-ARC world, a method could always just return objects >> with a +1 retain count, and the consumer could just assume that and always >> balance the retain. > > It could, but that results in _enormous_ numbers of retain/release calls. (I > speak from some experience, having once worked on performance optimization of > a project that did ref-counting this way.) > > It’s generally cheaper overall to use autorelease, and that was one of the > reasons NeXT invented it* (besides the obvious benefit of simplifying MRR > code.)
Autoreleasing return values by itself has no net effect on the number of retain/release operations compared to a scheme where return values are returned retained. In both cases there is a retain/release pair bracketing the return. In both cases an optimized function that is merely passing a returned value along can do so with no additional cost. The benefit of the autoreleasing convention comes when you can return an unretained value without a retain/autorelease pair, because you "know" that the object will live long enough for the callee to use it. This does in fact avoid lots of retain/release pairs in carefully written code. One cost of the autoreleasing convention is the autorelease pools themselves. Sometimes large numbers of otherwise-dead objects are kept alive by an autorelease pool. Another cost of the autoreleasing convention is the bugs introduced when you "know" that an object can be safely returned unretained but you are wrong. The traditional example is -[NSMutableArray objectAtIndex:]. It returns the array value unretained with no retain/autorelease. This is fine while the array continues to hold the value, but can fail if the array is destroyed or the object is removed from the array. ARC always retains and autoreleases when returning, for compatibility with non-ARC code. For safety reasons ARC never returns a bare unretained value and it always retains values that are returned to it. ARC does add an optimization where a cooperating caller and callee can safely avoid the retain/release pair around the return operation, effectively transforming that call into the return-retained convention. > * I’m not actually sure they did; there’s an earlier technique called > “deferred reference counting” that might be equivalent. Deferred reference counting is not much like autorelease. The goal of deferred RC is to accumulate many retain and release operations from a single thread and apply them all at once, in the hopes of reducing the cost of repeated refcount operations on a single object. It can be used with any parameter passing convention. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
