Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Charles Srstka <email@hidden>
- Date: Wed, 12 Jul 2017 16:09:51 -0500
> On Jul 12, 2017, at 1:24 PM, Jens Alfke <email@hidden> wrote:
>
>> On Jul 12, 2017, at 10:38 AM, Charles Srstka <email@hidden
>> <mailto: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.)
>
> —Jens
>
> * I’m not actually sure they did; there’s an earlier technique called
> “deferred reference counting” that might be equivalent.
How do you figure? Objects start with a +1 retain count, so returning that
object with a +1 requires no retain/release calls at all; just return the
thing. The client, in an all-ARC world, can then just assume the thing is +1
and use it without needing to retain.
Objective-C ARC actually attempts to approximate this by peeking up the stack
to see if the caller is ARC, in which case it skips the whole
retain/autorelease dance and returns the object as is. But this is apparently
not foolproof, since I often see autorelease calls showing up in Instruments in
ARC apps, and even when it does work, the lookup process is still going to be
more expensive than just returning the object.
Charles
_______________________________________________
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