Sparrow Forum

1. 

   pnutus
   Member

   The longer my game is on, the more the animations stutter. This made me think "memory leaks!". I profiled the app and saw that, yes, the memory footprint is constantly growing.

   I then profiled for leaks and saw thousands of SPMatrix, SPPoint and SPRectangle being leaked, but nothing else. I figured this has something to do with instruments not recognizing Sparrow's pooling system.

   However, isn't the point of the pooling system to reuse old instances instead of creating new? How come, then, that my app's memory footprint is steadily increasing? I never have more than maybe 20 SPDisplayObjects on screen (and in memory) at the same time.

   My game is in the prototype stage and has no bitmap graphics, it only uses SPQuads, SPTextFields and some Core Graphics-generated textures.

   The stuttering animations are SPTween animations, I'm not doing any dynamic animation.

   Are memory leaks the problem? Or could it be something else? I'm at a loss here, help appreciated.

   Posted 8 months ago #
2. 

   Daniel
   Primary Feather

   Hm, if I remember correctly, the pooled objects are not recognized as "leaks" by instruments, so that should be fine. But to be 100% sure, you can temporarily turn off memory pooling by adding a simple preprocessor define -- here's how to do it.

   Leaking memory alone should (normally) not make your game stutter, though. One thing that might cause that is if the number of display objects is constantly growing -- perhaps you have some objects with "alpha = 0" or "visible = NO" hanging around that don't get removed?

   A simple way to test that would be to add a recursive "numChildren" method that counts the total number of children of your game class. Log out the number of children regularly, perhaps you find something irregular!

   Posted 8 months ago #
3. 

   pnutus
   Member

   A simple way to test that would be to add a recursive "numChildren" method that counts the total number of children of your game class.

   A good idea. I did just that, but there were no irregularities.

   This is the code I used to count all children (in case anyone wants to do the same):

   - (int)countChildren:(SPDisplayObjectContainer *)parent
   {
       int ownChildren = [parent numChildren];
       int totalChildren = ownChildren;
       for (int i = 0; i < ownChildren; ++i)
       {
           SPDisplayObject *child = [parent childAtIndex:i];
           if ([child isKindOfClass:[SPDisplayObjectContainer class]])
           {
               totalChildren += [self countChildren:(SPDisplayObjectContainer *)child];
           }
       }
       return totalChildren;
   }

   Hm, if I remember correctly, the pooled objects are not recognized as "leaks" by instruments, so that should be fine.

   I'm confused. Should they show up in instruments or not? What happens when you profile one of your own apps?

   I disabled memory pooling, although to make the LLVM compiler accept it I had to change some code in SPPoolObject (I can send you a pull request on github, if that's okay.)

   This seems to have worked, the game doesn't stutter anymore, and instruments has reported no leaks so far. So there seems to be something wrong with the pooling system.

   However, I am using iOS 5, so that might be why it's not behaving. I think you've said earlier that you haven't started testing for iOS 5 yet. Maybe about time soon?

   Posted 8 months ago #
4. 

   Daniel
   Primary Feather

   Thanks for posting the code to count the children! This is a great way to rule out that problem.

   In iOS 4, Instruments does not report the pool objects as leaks. They pop up as being allocated, but it is recognized that the reference to the objects is not lost (thus, that it's not a leak).

   Ah, OK, you're using iOS 5 -- seems as if this really has to do with that, there's another thread mentioning it, too. I wonder if Apple changed how objects are allocated ... but I still hope it's just a bug.

   Until I have figured it out, I agree that you should deactivate pooling for now. Thanks for the pull request, BTW! I'll have a look at it asap! =)

   Daniel

   Posted 8 months ago #

RSS feed for this topic

Reply

You must log in to post.