Have you ever looked at the memory footprint for a long running loop in Instruments? Even though you may use a NSAutoreleasePool, the memory footprint constantly increases. I had to tweak my pool.
Say you want to sync data from your server to your iPhone or iPad APP. No matter what protocol you are using, you probably end up with a loop fetching data from your server and storing it locally. As mentionned, you’ll create a fetch thread:
-
- (IBAction) syncStart {
-
[NSThread detachNewThreadSelector:@selector(syncCore:) toTarget:self withObject:nil];
-
}
in which you iterate over a list of objects, fetch them, give feedback to the user, creating helper objects you put on auto-release. But your APP might end up eating more and more memory within that loop although you’re creating a sub-autoreleasepool you are releasing at the end of each loop:
-
- (void) syncCore: (id) dummyArg {
-
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
-
NSEnumerator *enumerator = [listToOperateOn objectEnumerator];
-
[UIApplication sharedApplication].networkActivityIndicatorVisible = YES;
-
while ((entry = [enumerator nextObject])) {
-
NSAutoreleasePool *subPool = [[NSAutoreleasePool alloc] init];
-
// do your stuff
-
[subPool release];
-
}
-
[UIApplication sharedApplication].networkActivityIndicatorVisible = NO;
-
[self performSelectorOnMainThread:@selector(syncFinished:) withObject:@"" waitUntilDone:NO];
-
[pool release];
-
}
Once you trace this code in Instruments, you see a climbing memory graph! Contrary to some examples, the Apple Docs prefer drain instead of release if you wish to release all collected objects!
-
[subPool drain]; // <-
-
[subPool release];
-
…
-
[pool drain]; // <-
-
[pool release];
A nice almost flat memory graph will appear in Instruments.
