Some stress tests on my Iphone app

Question

I ran a few stress tests on my Iphone app. The results are below. I am wondering if I should be concerned and, if so, what I might do about it.

I set up a timer to fire once a second. Whenever the timer fired, the app requested some XML data from the server. When the data arrived, the app then parsed the data and redisplayed the affected table view.On several trials, the app averaged about 500 times through the loop before crashing.

I then removed the parsing and redisplay steps from the above loop. Now it could go about 800 times.

I set up a loop to repeatedly redisplay the table view, without downloading anything. As soon as one redisplay was completed, the next one began. After 2601 loops, the app crashed.

All of the above numbers are larger than what a user is likely to do.

Also, my app never lasts long at all when I try to run it on the device under instruments. So I can't get useful data that way. (But without instruments it lasts quite a while, as detailed above.)

Answer 1

I would say you need to be very concerned. The first rule of programming is that the user will never do what you expect.

Things to consider:

• Accessor methods. Use them. Set up properties for all attributes and always access them with the appropriate getter/setter methods:

.

object.property = some_other_object;      -OR-
[object setProperty:some_other_object];

and

object = some_other_object.some_property;
object = [some_other_object some_property];

Resist the temptation to do things like:

property = some_other_object;
[property retain];

• Do you get output from ObjectAlloc? There are 4 tools from memory leaks, performance and object allocations. Are none of them loading?
• What do you get when the app crashes? EXEC_BAD_ACCESS or some other error?
• Balanced retain (either alloc or copy) and release. It is a good idea to keep every alloc/copy balanced with a release/autorelease in the same method. If you use your accessors ALL OF THE TIME, the need for doing manual releases is seldom.
• Autorelease will often hide a real problem. It is possible Autorelease can mask some tricky allocation issues. Double check your use of autorelease.

EDITED (Added based on your fault code) Based on your above answer of "Program received signal: 0". This indicates that you have run out of memory. I would start by looking for instances that your code does something like:

myObject = [[MyClass alloc] init];
[someMutableArray addObject:myObject];

and you do not have the "release" when you put the new object into the array. If this array then gets released, the object, myObject, will become an orphan but hang around in memory anyway. The easy way to do this is to grep for all of your "alloc"/"copy" messages. Except under exceedingly rare conditions, there should be a paired "release""/autorelease" in the same function. More often than not, the above should be:

myObject = [[[MyClass alloc] init] autorelease];
[someMutableArray addObject:myObject];