I am still scouring for things to remove so that I can get the footprint down for use in the tiniest MCUs. I also expect to release a new version of NxWidgets in the next few days that will incorporate a tiny window manager.

Big picture, my attitude is “if Apple say don’t do it, don’t do it”.

I have read up on autorelease pools, but that was about a year ago. I could do with a refresher. What I found frustrating about the books I’ve read is that they are all vague about how the pools and the autorelease method work. “Use autorelease,” they say, “if the caller needs to use the returned object. It will be cleaned up at some point in the future.” They leave out any information about exactly when the objects will be cleaned up or how.

My current understanding (based more on educated guesses than documentation) is that pools are arranged in a stack. The autorelease method adds a pointer to the current object to the top pool in the stack, which retains it. When the pool is drained, all objects it has pointers to are released.

Yep, I’m using @property and @synthesize. That’s another feature of Objective-C that I appreciate - properties deal with all that messy copying/assigning/retaining business when dealing with object trees. They’re quite well thought out.

Googling suggests that NSArrays are anywhere from 6x to 500x slower than C arrays depending on how you use them The overhead of repeatedly allocating, populating and deallocating the array can only make the difference greater. However, I’m using NSArrays in a number of other places and don’t have the same problem. The method in question was being called an awful lot by the AI, and refactoring so that arrays weren’t created at all fixed it.

You should also read about autorelease pools (which are of course obsolete in ARC) - your autoreleased objects are not necessarily alive till the next iteration of the main runloop - anyone in the call stack might have a pool in place.

If you switch to using real “@property”s you’ll find that more of the “should I release/retain” cruft disappears.

I’m surprised you found NSArray inefficient, but its not impossible. It might be worth ensuring that you aren’t writing your own iterators to search, rather than using existing functions to locate things. And if you know the size of your arrays in advance, make sure you use the correct initialisers because it will switch in different implementations under the covers that exploit the fixed characteristics.

Having said that, putting thousands of objects into an NSArray definitely killed the performance of at least one of my applications - you need to remember that when you take an object out of an array, NSArray sometimes has to retain/autorelease it to ensure that it doesn’t go stale while you are holding it. I think the use case they are protecting against is something stupid like

[myarray setObject:[myarray objectAtIndex:0] atIndex:0];

A no-op at best, but they try to ensure that it doesn’t crash on you anyway. Or so I believe …