autoreleasepool inside a method on ARC

Question

I am wondering if there's any benefit of using @autoreleasepool on an ARC code inside a method.

I mean this. Suppose I have a memory intensive method that is called several times in sequence. Something like

// this is my code
for (id oneObject in objects {
  [self letsUseMemory];
}

and then

- (void) letsUseMemory {

  // heavy use of memory here

}

and I do this

- (void) letsUseMemory {

  @autoreleasepool {

    // heavy use of memory here

  }

}

Is there any benefit? I mean, the method variables will be deallocated anyway when the method finishes, so adding an autoreleasepool there, in theory, will do any benefit, right?

Or will autoreleasepool inside that method speed the deallocation?

thanks.

score 3 · Accepted Answer · answered Nov 27 '12 at 17:51

Is there any benefit? I mean, the method variables will be deallocated anyway when the method finishes, so adding an autoreleasepool there, in theory, will do any benefit, right?

It depends. Any autoreleased temporary objects will not be deallocated until the pool drains, regardless of whether you're using ARC. I.e.:

NSString* foo = [NSString stringWithFormat:@"Bar: %@", baz];

Without an enclosing @autoreleasepool, that object instance may hang around until you return to the run-loop. If that line of code exists within a loop, you may be accumulating a large number of these temporary objects.

The general rule of thumb is that if you have a potentially large loop that may create autoreleased objects, wrap the inside of the loop in with an @autoreleasepool.

It's less common and perhaps somewhat meaningless to wrap a single method in an @autoreleasepool because it would usually only have meaningful effect if the method was called many times in a loop. Putting the @autorelease pool in the loop makes the intent more clear.

score 1 · Answer 2 · answered Nov 27 '12 at 17:41

1

There are a number of "it depends" things going on there, I believe.

Starting with the obvious, if there are no autoreleased objects, it doesn't matter. If your code goes right back to the run loop after your enumeration finishes, it doesn't matter.

That leaves the case where the method containing the enumeration is used to do a bunch of initialization and then continues on with more processing. For that one, you could benefit by getting rid of temporary objects that were marked for later release.

answered Nov 27 '12 at 17:41

Phillip Mills

30,888
4
42
57

I am talking about an ARC environment. Yes, the loop is executed several times but there is more code after the loop that may be intensive. And yes, I am talking about memory intensive stuff, or in other words, a lot of initializations. – Duck Nov 27 '12 at 17:47
Got it, so that falls into the case where the loop is creating stuff that won't be released immediately (because of the "more code") and could benefit from `@autoreleasepool`. (I wish there was an Xcode debugging option to show where ARC was inserting its memory management logic.) – Phillip Mills Nov 27 '12 at 18:06

autoreleasepool inside a method on ARC

2 Answers2