Re: ARC Retain Cycles
Re: ARC Retain Cycles
- Subject: Re: ARC Retain Cycles
- From: Dave <email@hidden>
- Date: Fri, 25 Apr 2014 10:45:24 +0100
On 25 Apr 2014, at 04:45, Graham Cox <email@hidden> wrote:
>
> On 25 Apr 2014, at 11:24 am, Dave <email@hidden> wrote:
>
>> I always knew autorelease was bad news!
>
>
> No it isn't, at least not inherently.
Inheriently it leads to data dependant methods/code and that is definitely bad news.
> But if you don't properly understand it then it can bite you. You've trodden this path before, and I don't want to rehash all that, but you were wrong then as well. If you spend a little time with manual memory management thinking in terms of object ownership, the conventions and rules become really obvious. Moving to ARC does not, I think, remove the need for the same understanding. In some ways it makes it more critical.
I do understand, it wasn’t my lack of understanding that was the problem. It was finding where autorelease was being used in the call chain and draining the pool.
> You cannot avoid autorelease - the frameworks must use it to be consistent with the established rules, so even if you avoid it religiously in your own code (and it is just dogma to do so) then you still have to deal with objects returned by other code.
It’s not dogma! autorealease meant my App peaked at 150MB, whereas it needed 10 MB! Autorelease caused 140 MB of data to be useless held in memory for the duration of the Thread for no good reason.
You can’t avoid autorelease, you need to do some work to undo it ASAP to stop the memory building up too much. In this case the solution is to copy the data into new objects and then drain the pool. Works a treat - you can’t avoid it BUT you can undo it!
At the top my app looks like this:
-(void) loadDownloadList
{
UIImage* myImage;
for (………)
{
myImage = [self.pServerCommandAPI newRequest];
}
}
The call chain for this goes something like this:
myImage = [self.pCommandAPI newRequest];
Test loadDownloadList
Command API newRequest
ServerAPI newRequest
ServerAPI newSyncRequest
NetworkAPI newSyncRequest
iOS7 dataTaskWithURL: <————— Returns Autoreleased Objects in Block Statement
The call to iOS 7 is new and is what was causing the problem, before it called another Class that didn’t return autoreleased objects. Because all the method names follow the “new” naming rule, this work wonderfully in non-ARC systems and lets your App run with a very small memory footprint.
Converting to ARC doesn’t break this, the problem occurs as soon as you start injecting autorelease object into the call chain. There are a couple of other places like this where I have to undo the OS’s use of autorelease or my App will have a muchos mas grande Peak Memory footprint.
The case in point is living proof that autorelease is bad news, 140 MB worth of proof! If you can’t see it then that’s dogma!
Happy Friday
Dave
_______________________________________________
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