Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Greg Parker <email@hidden>
- Date: Wed, 12 Jul 2017 14:03:06 -0700
> On Jul 12, 2017, at 11:24 AM, Jens Alfke <email@hidden> wrote:
>
>> On Jul 12, 2017, at 10:38 AM, Charles Srstka <email@hidden>
>> 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 email@hidden <mailto:email@hidden> Runtime
Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden