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