On 26 Apr 2014, at 15:40, Glenn L. Austin <gl...@austin-home.com> wrote:
> On Apr 26, 2014, at 4:29 AM, Dave <d...@looktowindward.com> wrote:
>
>>
>> On 26 Apr 2014, at 08:27, Jim McGowan <jim_mcgo...@mac.com> wrote:
>>
>>>
>>> On 25 April, 2014 5:45:24 pm HKT, Dave <d...@looktowindward.com> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> ‘Autorelease’ wasn’t causing your app to use 150mb, it was your loop that
>>> was causing the memory usage.
>>
>> Yes, because of autorelase! Take autorelase out of the equation and it
>> doen’t use 150MB!
>
> Think of autorelease as simply adding the object to a list of objects to
> release when the autorelease pool is drained or released.
Yes, I know, it’s naff.
> 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.
> When executing a loop that allocates a lot of memory as a part of its
> operation, it's good practice to wrap the contents in an @autoreleasepool {}.
But the loop works fine with no drains! The object at the top layer is +1
retained (newXXX) so it gets released straight away.
-(void) downloadImages
{
UIImage* myImage
for (someCondition)
{
myImage = [self.pServerAPI newImage];
[myImage release]l; //If Non-ARC - removed
for ARC.
}
}
From looking at this code, how is it possible to assertain that it is using a
large amount of memory? When I look at this, I don’t think ahhhhh, it’s
probably allocating a large amount of autoreleased blocks, so I’d better drain
the pool! I think it’s allocating one non-autoreleased Image.
That’s the problem and why autorelease is bad news! It isn’t instantly obvious
that a large amount of memory is being used.
> Autorelease isn't causing your problem,
If the OS didn’t allocate autoreleased objects there wouldn’t be a problem at
all, it does though so it becomes neccessary to have to worry about cleaning up
after the OS.! You can twist the language any way you like, but the problem is
autorelease, not anything else.
Autorelease is really the pits IMO, use it at your peril, it’s just a shame the
OS pollutes an otherwise well *managed* memory scheme.
Before I converted to ARC and merged in some code, it worked without any drains
and didn’t use 150 MB. The introduction or side effect autorelease behind the
scenes caused an otherwise fine loop into a memory hogger. Using auto release
caused me to have to profile the app carefully and find the problem. This
probably took 1 to 1.5 days to do, if the OS didn’t use autorelease, I wouldn’t
have had to spend that time finding and cleaning up after the OS!
Really, what OS other, makes you clean up after it?
Cheers
Dave
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
