I think that tight loop may be one thing, the appropriate scoping of variables
is another. When writing loops I tend to use lots of local variables that is
alloc/init'd and that will give clang an extreme good idea about what is going
on when the loop folds and variables all go out of scope. I don't put
autorelease pools in loops a lot but my code never had any crazy memory usage.
And if some extreme care of memory is needed in ARC code I will drop to some CF
objects (like NSMutableArray *arr = (__bridged NSMutableArray
*)CFArrayCreateMutable(NULL, 0, NULL); and this will make a mutable array that
is not managed by ARC) and bridge cast them to keep ARC out of managing those
object, and CFRelease them after I am finished with them.
Sent from my iPad
> On Apr 26, 2014, at 7:29 PM, 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!
>
>> If you have a loop where each iteration is going to create/fetch/copy a
>> significant amount of data, then it is pretty standard practice to have an
>> autorelease pool inside the loop, as otherwise you are depending on the next
>> pool in the chain, which is probably the main thread’s pool which is only
>> popped once per event loop interation.
>
> Only if you use autorealease in your own code, which I don’t, and most of my
> code that interfaces to the OS is encapsulated so all I need do is drain the
> pool at this point. I don’t use autolrelease so I don’t need to worry about
> draining any pools!
>
>>> 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!
>>
>>
>> I don’t really understand what you mean by “undo it”, but I the thing to
>> remember is that autorelease pools are not like garbage collection, you have
>> to be responsible for them in your own code in the same way that you are
>> responsible for balancing new/init/copy/retain with release.
>
> Except now, in ARC you don’t have to be responsible for balancing
> alloc/release, BUT in order to get the best out of the compiler its better to
> follow the new/alloc naming convention, since it stops ARC making the object
> auto releasable which was the first problem.
>
> By undo, I meant if the OS (or whatever) returns an autoreleased object, I
> copy it into a +1 retained object, then drain the pool, and prefix the name
> of the method with new or alloc. So no one above this point in the call know
> or cares about autorelease,
>
> Something like this:
>
> -(NSString*) newThingFromOS
> {
> NSString* myString;
>
> @autoreleasepool
> {
> myString = [[xxxxxx getAutoreleasedString] copy];
> }
>
> return myString;
> }
>
> 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/xcvista%40me.com
>
> This email sent to xcvi...@me.com
_______________________________________________
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
