Re: Silly ARC question - explanation requested
Re: Silly ARC question - explanation requested
- Subject: Re: Silly ARC question - explanation requested
- From: Alex Zavatone <email@hidden>
- Date: Wed, 04 Jun 2014 17:26:38 -0400
On Jun 4, 2014, at 4:07 PM, Ken Thomases wrote:
> On Jun 4, 2014, at 2:24 PM, Alex Zavatone wrote:
>
>> As it turned out, my coworker had created a dispatch_async thread to start processing the video and within it, started at a framecount of 0, incremented it within a while(true) loop and grabbed the frame every time there was a new framePixelbuffer. All within the while(true) loop.
>>
>> Well, OF COURSE memory's not going to be released and of course it's not a leak, but here's where I need some help understanding how to explain this and why this approach is a bad idea within Cocoa.
>
>> But within the convert to grayscale routine in the external lib where we create a CGContextRef and later issue a CFRelease on it, memory is allocated within CGContextDrawImage. However it builds up for every frame grabbed and is not released until the while loop is exited. This is where we lose 3.52 MB each pass, but it's not really lost since it's allocated but can't be released by ARC since it's within a while loop.
>
>> My first inclination is, "DUDE. You silly rabbit! You created an async process, then wrapped the whole video processing section in a while loop and you expected memory to get released by ARC? ARGH! WHY? Bad codemonkey, bad!"
>
>> This is where I'm seeking a better explanation than I can give. Does anyone have a better explanation for "this is why we never do things this way - even though you can wrap time consuming operations in repeats and whiles, it doesn't mean that you should and expect ARC to work"?
>
> You have a misconception as illustrated in the above quotes. I think you think of ARC as a garbage collector that needs idle time or for execution to return to the frameworks in order to work. It is not and does not.
>
> For the most part, ARC just inserts retains and releases just as you would in manual retain-release mode if you were extremely careful. (The exception is weak pointers which get nil-ed out when the pointed-to object is deallocated. There's also the returned-autoreleased object optimization that you couldn't achieve on your own, but that's not relevant here.)
>
I was jumping to that conclusion because I had never seen ARC code in a dispatch_async thread fail to release memory in low memory conditions.
I'd never seen a situation where setting a variable to nil didn't release the memory under ARC before, let alone keeping every instance allocated even if I'd set it to nil.
Our call to the grayscale conversion would allocate 3.52 MB every time it was called and stored the UIImage in a local. Even if I tried to invalidate the image, nil the memory would never get released until after the while loop exited.
I made the while loop exit after 100 frames and our 172 MB of allocated RAM instantly hopped back down to 2.8 MB.
Honestly, I'd expect that as the loop looped, the previous instance of the grayscale image would immediately be released, but somehow the while loop or the dispatch_async prevented this.
I guess a better question is "why/how does the while loop seem to delay ARC's memory releasing, or was this caused by the while loop being inside a GCD dispatch?
Thanks Ken.
> It sounds to me like this is just the classic sort of peak memory usage you would get with autoreleased objects with manual retain-release code if you don't drain the autorelease pool in your loops.
So, while this feels to me at if it's encouraging this type of problem to pop up, it is acceptable practice, as long as the critical elements are in autorelease pools and are manually drained?
It just seems that a much better approach would be if the frame processing was one async thread for one frame at a time and was only called upon a frame change by watching hasNewPixelBufferForItemTime. Then when that frame thread is completed processing, execution isn't stuck in a while loop while being inside one large asynch-ly dispatched process.
Cheers.
_______________________________________________
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