5

I ran my app using Instruments and found that one of my methods' [UICustomButton loadButton..]" count under allocation is always increasing (see screenshot below) -

enter image description here

The method in question is triggered whenever I scroll a tableview and when the cell is visible.

My questions are

1) What does the count actually mean? Is it normal for it to keep increasing?

2) Is the increasing count the reason why my scrolling becomes increasingly laggy?

Zhen
  • 12,361
  • 38
  • 122
  • 199

2 Answers2

4

The count in the instruments show the number of instances of a given class your application has created that are stil alive. So it is normal to increase up to the point where your application has created all the objects it needs to have, then it should remain more or less constant (more or less because you will be probably creating and releasing objects all the time).

If the count never stops increasing you probably leak objects - create and not release properly. This may lead to slow down (if you are creating performance expensive objects or have to work with all the instances which are getting more and more for example), it will definitely lead to crash after you've used more memory that your app is allowed to use.

Did you reuse cells in tableView? You should, otherwise you'll get this very effect: increasing instance count, increasing memory usage, slow scrolling and crash after the time.

Tomasz Stanczak
  • 12,796
  • 1
  • 30
  • 32
  • Stanczak, thanks for your insights, that was my fear as well. Strange thing was that I did reuse the cell data and the problem did seem to arise due to the way I was creating the buttons in the cell, If you do not mind, can you refer to my other question http://stackoverflow.com/questions/6567799/objective-c-how-to-resolve-leak-in-code-results-from-instrument which actually has the code and screenshots? Appreciate your help on this – Zhen Jul 04 '11 at 13:54
  • 1
    i'd like to see your cell creation code. i suspect you are adding a button to the cell not just when the cell is created, but each time it is loaded with data – bshirley Jul 04 '11 at 18:22
  • @bshirley, my code can be found in my other question http://stackoverflow.com/questions/6567799/objective-c-how-to-resolve-leak-in-code-results-from-instrument . Appreciate if you can help to take a look and give me some advise on what can be done. Thanks in advance – Zhen Jul 05 '11 at 00:22
0

Now as far as i have understood the concept of the count i will try to explain this, count refers to the number of ownership claims that you outstanding on a object and can be checked with the help of a function called as the -retainCount, but you should never pay any attention to the value of the retain count as its never correct and always confusing,

you don't know what's being retained, why it's being retained, who's retaining it, when it was retained, and so on.

For example:

You'd think that [NSNumber numberWithInt:1] would have a retainCount of 1. It doesn't. It's 2.
You'd think that @"Foo" would have a retainCount of 1. It doesn't. It's 1152921504606846975.
You'd think that [NSString stringWithString:@"Foo"] would have a retainCount of 1. It doesn't. Again, it's 1152921504606846975.

Basically, since anything can retain an object (and therefore alter its retainCount), and since you don't have the source to most of the code that runs an application, an object's retainCount is meaningless.

If you're trying to track down why an object isn't getting deallocated, use the Leaks tool in Instruments. If you're trying to track down why an object was deallocated too soon, use the Zombies tool in Instruments.

But don't use -retainCount. It's a truly worthless method.

Radix
  • 3,639
  • 3
  • 31
  • 47
  • 1
    The questioner doesn't mention `-retainCount` at all. The question is about the Allocations tool in Instruments. – Rob Keniger Jul 04 '11 at 11:38
  • @Radix, thanks for your response, so basically the large numbers should have no relevance to the poor performance? – Zhen Jul 04 '11 at 11:59
  • @Zhen: Ya like they make no sense at all, you can check for yourself, alloc init a label and check its retain count – Radix Jul 04 '11 at 12:03
  • I'd disagree. If you understand what's going on retainCount is quite meaningful. – Hot Licks Jul 04 '11 at 12:09
  • retainCount is very important, actually it is foundation of the iphone memory management so it is crucial to understand and use it right. In iOS you never free objects by yourself: you release them and wait for the runtime to free them. Retain increases retain count, release decreases retain count, runtime frees objects if their retain count goes to 0. As easy as it sounds it is quite complicated to get right, but if done wrong your app will crash. – Tomasz Stanczak Jul 04 '11 at 12:48
  • @Tomasz: ya right that is 100% correct but why is it that when i alloc and init a label or do the things that are mentioned above i get the wrong retain count, could you explain that to me – Radix Jul 04 '11 at 12:53
  • For string constants it will be UINT_MAX so that they never get released. For NSNumber it looks like for numbers up to 12 you get a second copy of the number, thus retain count of 2 (not my discovery though, look here: http://stackoverflow.com/questions/656902/why-has-nsnumber-such-strange-retaincounts). Foundation does a lot of clever things under the hood for us, so I actually agree that this is often a useless method for debugging :-) I just felt like having to mention its importance. Still it can help if you are debugging your own code and know who is retaining what. – Tomasz Stanczak Jul 04 '11 at 13:05
  • As stated, strings and small numbers are treated specially. (Essentially the same special-casing is done in Java, BTW.) But most other objects have a meaningful retain count, and it can tell you a lot. It should not, eg, keep growing. And the count should be at least as large as the number of retains you know (or believe) have been done on it (and not released). I've debugged several problems in my (short) iPhone career by checking retainCount. – Hot Licks Jul 04 '11 at 18:32
  • @Tomasz: ya like that's what i meant it has nothing to do with the debugging part, i haven't used this method till now and i just keep a record about the flow of the application about when and where i have created the objects and to release them like a good boy. What i believe in is that for each and every stuff in programming you have a pretty neat explanation but when i googled for the retain count like why does the count show unexpected results then i was not pleased with the answer and stopped using this method and things are going pretty neat till now. – Radix Jul 07 '11 at 06:01
  • Hi @Daniel, if retain count has no use then tell me why it has been deprecated in the new sdk, with a brief explanation or is it something like its still active and all, what i think that apple has introduced garbage collection to the new sdk just like they have for their mac os environment could you provide some guidance to us on that. – Radix Aug 02 '11 at 07:20
  • 1
    @Radix -- Depends on what platform you're talking about. Retain count is meaningless in a GCed environment, but that isn't the normal environment on phones. – Hot Licks Aug 02 '11 at 11:55