Re: ARC Retain Cycles
Re: ARC Retain Cycles
- Subject: Re: ARC Retain Cycles
- From: Dave <email@hidden>
- Date: Mon, 28 Apr 2014 09:17:50 +0100
On 27 Apr 2014, at 23:01, Glenn L. Austin <email@hidden> wrote:
>
> On Apr 26, 2014, at 10:32 AM, Dave <email@hidden> wrote:
>
>>> Autorelease isn't causing your problem, it's that you're misunderstanding what autorelease pools are and do. What Dave wrote is correct: it was your loop that was causing the memory usage, since each iteration through the loop added more objects to the autorelease pool without either draining or releasing the pool.
>>
>> Autoreleaseis is to save the programmer having to worry or think about releasing memory. It is an awful invention. It’s quite possible to manage your own memory quite easily so I don’t see the point of using it, especially now we have ARC which in theory could do with with Autorelease altogether.
>
> That's entirely incorrect. Autorelease means that the routines that allocate memory MUST either use it or release it. It's NOT an option.
Don’t understand this at all? What do you mean by “MUST either use it or release it"? If I allocated an autoreleased object, I don’t *have* to use and I can’t release it without a crash!
Ahhhhh, from re-reading it I think you meant to say non-autoreleased object. Yes, you have to release it yourself if the name of the method returning the object begins with alloc/new/copy. Well, actually you don’t now if you are using ARC, but for non-ARC yes.
Yes, autorelease allows a method to return an object that doesn’t need to be released by the code explicitly, which saves the programmer having to worry or think about releasing memory which is what I said originally, so it’s not “entirely incorrect”.
> On the other hand, by returning an autoreleased pointer from a method/function, you can always *guarantee* that the memory will be released eventually. Without autorelease, all of the callers of your method/function are *required* to manage memory.
>
> However, inside of a loop you need to manage your autorelease pool. This is something that every developer has to deal with -- and autorelease pools make your code far simpler.
>
> It's similar to using exceptions vs. putting all of your error-handling code inline. Sure, you can not use exceptions, but…
I’m not talking about returning an autoreleased object really, as you can do something about those and they produce a limited, known number of objects. What I am tallking is using autorelease within a method that allocates a large number of temporary objects and leaves them in the pool on return.
For instance,
[someOSClass someMethod];
Might leave 150 MB of objects in the pool, and there is no way of telling if it will or not ahead of time, meaning that if and when it does start hogging memory, you have to spend a lot of time running the profiler and playing around with draining the pool at various strategic place in your code. In my experience this nearly always happens quite a long way into the project and it invariably means you have to revisit code that has been working solidly for quite some time.
Cheers
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