views:

4868

answers:

4
+2  Q: 

Autorelease iPhone

Coming up towards the end of developing an iPhone application and I'm wondering just how bad is it to use autorelease when developing for the iphone. I'm faced with some fairly random crashes and, so far, I can't pinpoint it to anything other than sloppy memory usage.

As a Cocoa newbie I remember initially reading a guideline document that strongly suggested avoiding autorelease in favor of manual retain/release for iPhone. However, a more 'senior' Cocoa developer came on board early on (who ironically has been let go since), who used autorelease all over the place. Admittedly, I was went into "monkey see monkey do" mode, and it appears to be coming back to haunt me (I'm now the only developer on the project).

So what to do next? It seems to me that I have to branch the code and try to go through and replace, where possible, autorelease code keeping my fingers crossed that I don't inadvertently break the app. It seems a lot of library calls result in autoreleased objects like stringWithFormat and pretty much anything where I'm not using alloc myself. Any other gotchyas and/or suggestions I should be looking out for? Thanks Cocoa gurus.

+10  A: 

Using release instead of autorelease can improve memory usage in tight spots (which is good on the iPhone), but it's not going to help at all with crashing if you're not following the retain / release rules. I would read a few tutorials on memory management in Obj-C if you're still a little hazy on what you should be doing, and then go after those crashes using the debugger and crash reports to find out where you're over releasing objects. This and this are two good places to start.

Marc Charbonneau
A: 

For iPhone performance reasons, Apple suggest that, whenever possible, you shouldn't use autoreleased objects. Instead, explicitly release your objects when you are done with them.

August
Can you add a reference?
Nikolai Ruhe
I have no reference. This was something suggested in one of their Tech Talks.Basically, when you autorelease an object, it hangs around for an arbitrary period of time until the system can destroy it. This means that while it may be "gone," it's still using resources -- something very valuable on the iPhone.By explicitly releasing objects, you get those resources back immediately.
August
+2  A: 

More important than the autorelease or manual-release choice is how often you alloc and dealloc your NSAutoreleasePools. Since most of the Cocoa frameworks use autorelease liberally, you need to have a proper pool draining strategy. Once that is in place, the choice of whether to release or autorelease becomes much less an issue.

That being said, the only areas you should worry about are tight loops--allocate and release an NSAutoreleasePool every few iterations for best results; and when you have spawned another NSThread that doesn't have a Runloop--create a pool and drain it every so often becomes idle. Since most applications only allocate a small amount of data per event, UIKit's strategy of allocating the pool before the event is dispatched and releasing it after the dispatch returns works very well.

rpetrich
A: 

Using autorelease pools means that you might be leaving some unused memory lying around. Since the iPhone has less memory to go around, you might improve performance if you free up unneeded memory as soon as possible, rather than letting it sit around taking up resources while it waits for an autorelease.

has