- Faades for Integration
- Walking the Tree
- Generating HTML
- Syntax Highlighting
- Autoreleasing Performance
- Final Thoughts
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Autoreleasing Performance
It's always tempting to optimize code, and it's a temptation that most programmers learn to resist shortly after the first time they try maintaining code someone else has optimized.
As I said earlier, the first time I ran this unoptimized program, it took a fraction of a second to run. If I'd spent a few minute optimizing it, I'd have spent more time than I'd have saved over the number of times that I ran it, even if I made it run in no time at all.
In another program that I wrote with some similar code, however, there was some opportunity for optimization. I noticed that my code was running slowly. The first thing I tried was running top, to see if another process was using my CPU. This showed me that the CPU load was only about 20 percent, which was surprising when I was running a compute-bound process.
Looking more carefully, I saw that the program I was testing had consumed more than 500MB of RAM and was growing at about 10MB/second. It turned out that this was inside a loop that was allocating a lot of short-lived objects.
It's a very common pattern in Objective-C to use autoreleased objects as temporaries. There are two ways that you might do this. You might get an autoreleased object returned from another method, or you might create the autorelease object yourself, typically by using a named constructor. For example, you might create a temporary string object like this:
NSMutableString *buffer = [NSMutableString string];
This is equivalent to:
NSMutableString *buffer = [[[NSMutableString alloc] init] autorelease];
This is convenient, because it means that you don't have to worry about destroying the object—it will be cleaned up for you later. The problem is that “later” might be quite a long way in the future. Typically, it's at the end of the current run-loop iteration.
If you have a line like this inside a loop, then you would be allocating a new object each iteration, but not destroying it until the end of the run loop. This isn't quite a memory leak, but it looks a lot like one.
Most of the time, this isn't a problem because you are only meant to do a small amount of work each time the run loop runs. For non-interactive applications (or even threads), this may not be the case, and memory usage can balloon.
Fortunately, it's usually easy to fix. You can simply add an extra autorelease pool. This is quite simple:
while (someCondition)
{
NSAutoreleasePool *pool = [NSAutoreleasePool new];
@try
{
NSMutableString *buffer = [NSMutableString string];
// Other stuff with temporary objects.
}
@finally
{
[pool release];
}
}
There are a few things to be careful about here. The first is to remember to include the @finally block, to make sure that the objects are automatically destroyed, even if the stack is unwound by an exception. This is not entirely necessary. Autorelease pools are arranged in a stack, and trying to destroy one that has children that have not been destroyed will also destroy the inner ones, but it means that you won't accidentally defer destruction (which is the problem that you're trying to solve in the first place).
The second thing to remember is that you can't pass autoreleased objects out of the @try block. If you want something to persist outside of the block, then you need to send it a -retain message before destroying the autorelease pool, then an -autorelease message afterwards. This will add it to the next autorelease pool up the stack.
If you are creating the temporary objects yourself, you can dispense with the autorelease pool entirely and just explicitly release them later. The loop would instead look like this:
while (someCondition)
{
NSMutableString *buffer = [NSMutableString new];
@try
{
// Other stuff with temporary objects.
}
@finally
{
[buffer release];
}
}
One of the main reasons that people resort to using autoreleased objects in the first place is that this is quite tedious. You need to make sure that every possible exit from the scope—including exception throwing—has a -release message for every temporary object. Fortunately, GCC introduced an extension to C that makes this much easier.
The cleanup attribute uses the same mechanism that is used to generate C++ object destructors for on-stack objects. It lets you define a destructor for a variable, like this:
__attribute__((cleanup(releaseObject))) NSMutableString *buffer = [NSMutableString new];
At every point where the buffer variable goes out of scope (including in an implicit exception cleanup block), the compiler will insert this:
releaseObject(&buffer);
You can define this function simply as:
void releaseObject(id *obj)
{
[*obj release];
}
This is quite a lot of typing too, but fortunately this version is easily reusable. In the EtoileFoundation framework, I defined a macro that uses this facility, so the entire loop would now look like this:
while (someCondition)
{
STACK_SCOPED NSMutableString *buffer = [NSMutableString new];
// Other stuff with temporary objects.
}
The cleanup function is defined in the header, and the STACK_SCOPED macro defines the attribute. You can now use buffer almost as if it were an autoreleased object, and it will be automatically cleaned up for you as it leaves scope.
After making this tweak to my program, it went from taking a long time and a huge amount of memory to finishing in less than a second and using 30MB of RAM at peak. This is a big improvement over several minutes and hundreds of megabytes of RAM.
Most of the time, you don't need to do this in Objective-C projects. It's important to remember that you can, for the few situations where you do need to. The Objective-C philosophy includes the idea of “no magic.” Autorelease pools are simple—you could easily implement your own version—and understanding exactly how your Objective-C code is executed makes it easy to optimize it.