Question

The run loop for the secondary thread of my application is below.
It has a nested control loops.

• The outer loop runs for the duration of the application
• The inner loop runs while one view is open, then the thread waits while the view is not open.
• Passes through the inner loop are short, a fraction of a second.

My code does not knowingly leave any autoreleased objects in unreleased pools, but I do not know what the OS is doing.

In the main thread, cocoa wraps an autorelease pool around every pass through the run loop.
In this secondary thread, I believe the closest equivalent is a pass through the inner loop.

The inner autorelease pool wraps each pass through the inner loop.

The middle pool wrap around the inner loop, so that objects created and autoreleased at this level are not held until the application terminates.

the outer pool wraps the whole runloop.

How can i determine what effect the creation and release of all these pools is having on the speed of my code.
How can I determine whether all three pools are necessary or overkill?

code and explanation:

- (void)processLoop
{

    NSAutoreleasePool * outerPool = [[NSAutoreleasePool alloc] init];
    [processCondition lock];

    //outer loop    
    //this loop runs until my application exits
    while (![[NSThread currentThread] isCancelled])    
    {
        NSAutoreleasePool *middlePool = [[NSAutoreleasePool alloc];
        if(processGo)
        {
            //inner loop
            //this loop runs typically for a few seconds
            while (processGo && ![[NSThread currentThread] isCancelled]) 
            {
                NSAutoreleasePool *innerPool = [[NSAutoreleasePool alloc]; init];
                //within inner loop
                //this takes a fraction of a second
                [self doSomething];
                [innerPool release];
            }
            [self tidyThingsUp];

        }
        else
        {
            [processCondition wait];
        } 
        [middlePool release];
    }
    [processCondition unlock];
    [outerPool release];
}

the combination of:

• an inner while loop
• NSCondition *processCondition
• toggling processGo between YES and NO

allows me to stop and start the inner while loop without cancelling the thread.

if (processGo == YES)

execution enters the inner while loop.

When the main thread sets

processGo = NO

execution leaves the inner while loop and tidys up
on the next pass of the outer loop, execution hits

[processCondition wait]

and waits

if the the main thread resets

processGo == YES

and calls

[processCondition wait]

execution re-enters the inner loop

Answer 1

I really can’t give too definitive an answer without knowing more about what some of those methods do, but the big concern when applying autorelease pools has to do with the number of objects each pool handles.

There’s an interesting blog post out there that looks at the effect of additional autorelease pools on the creation and destruction of a million instances of NSObject. The gist of the post says that “autorelease pools are cheap”: the program continued to get more efficient with fewer objects per pool right up to somewhere around the 10 objects/1 pool ratio. (After that it skyrockets, because you’re closing in fast on creating a pool for every object, which is obviously silly.)

The best thing for you to do is figure out roughly how many objects each release pool would be dealing with. For example, if your inner pool is handling a hundred objects each pass, and there are a hundred passes, getting rid of that pool would add ten thousand objects to the middle pool – this would be a Bad Thing. On the other hand, if the inner pool handles one object each pass for ten passes, then sure, go ahead and get rid of it.

If you can’t make the decision, see if you can find a way to time the performance of just the inner loop or just the code executed within the scope of the middle pool, then add/remove autorelease pools as necessary. And remember: autorelease pools are cheap.