Hey, im running cocos2d, box2d and several particle systems on the iPhone 4.
I've completed my first level which has numerous sprites allocated as well.
I have set my FPS limit to 30fps.
When the game first runs, it runs well, at a solid 30fps. This continues for about 3-4 minutes of smooth gameplay.
But after a while the fps starts to drop, and it turns into a gradual decline until it hits around the 12fps mark.
I remember I had this problem with a previous game that I abandoned.
Is this caused by a memory leak, possibly from not deallocating items??
In my (void)dealloc methods, I am inputting all my allocated releases, could I have missed one? Or is there some other possibility i'm not considering?
Thanks!
Sounds like you're running out of resources. I'd try Instruments as suggested by SB. Instruments can check for leaks using the Allocation instrument. You could also try the OpenGL profiling suite.
I have the same problem and I cannot get the resolution. When I unload the entire scene and reload it again, everything is back to normal. So it definitely seems to be a leak somewhere, but even with instruments I cannot find the source of it.
The total memory usage is not growing, no leaks reported, so I have the feeling that something in Cocos2d or in Chipmunk increasing the load.
I am using sprites which are moving in and out from the screen in a random manner and creating nd destroying them every time. Can it be that something is not released properly and Cocos or Chipmunk is still calculating with those items?
Related
I'm trying to debug a mysterious app crash that happens after running the app for a few hours.
My hunch is that this may be memory related, as I've not done any memory optimization since starting to build my app.
I'm looking at my application with the "allocations" instrument and I see these numbers:
All allocations 4.70mb
Living 51072
Transitory 357280
Overall Bytes 100.23mb
Overall 408000
Which is the important number here? Does my app take 4.7 Mb of memory or 100 Mb? At which point should I be concerned about my app being killed for memory reasons? I want to avoid premature optimization :)
Since I'm using ARC and TabBarController, most of the controller related memory seems to be out of my hands, unless I find out how to create a tab and lazily init a controller when that tab is first touched.
Thank you!
I have a problem right now. I develop game application for iPad with cocos2d. In my application, I use background music. When I use cocos2d music method SimpleAudioEngine, i got leak. However, my bos don't want have a leak in our application. Any other way to play background music except using SimpleAudioEngine and not get a leak?
Thanx before. Regards.
How do you know that you have a leak? Often times what is reported as a leak truly isn't a leak, or a leak in your own code. In particular the static analyzer only makes suggestions but is quite often wrong about his assumptions.
You may also want to contact the library author Steve Oldmeadow, he can be found on the cocos2d forum. At least he may be able to confirm a bug, or explain why it's not a leak.
Secondly, I wouldn't put too much weight on the leaks. Let's assume you're leaking 16 Bytes every time you start a music. You would have to start the music 16.000 times to have leaked 16 KB. How likely is this in your app, and how badly do you "need" those 16 KB?
Third, tell your boss you fixed the leak. If he doesn't want leaks in the app, he's obviously not a (good) programmer. I know it's a lie, and I know there's going to be programmers who'll hate me. But really before you spend hours or even days to find a "better" way of playing music (possibly with other side effects) rather than using what's tried and true in hundreds of iPhone apps, such a white lie is going to save your boss a bunch of money.
I think that too many people think that leaking memory equals an app that crashes often. Such is not the case, unless the leaks are significant, resulting in out of memory errors or in some scenarios memory fragmentation.
You can use SoundMaster engine instead of CocosDension Sound Engine. ARC support, memory management (NO LEAKS) and many other features like fade in/out, relative volumes for effects or cross-fades.
Why does NSColorPanel accumulate memory usage? Try it:
Create a brand new cocoa-based application in Xcode
add a sinlge NSColorWell to the main window
Run app and open a memory monitor (ex. Activity Monitor)
Click the colour well to bring up the NSColourPanel
Click and drag your mouse on the colour wheel, twirling it around and around for a while, watching the app's memory usage
Result: Memory keeps climbing, slowly but surely (4-5Mb's in about a minute). In my tests, it seems to hit some sort of barrier after climbing about 4 megs, after which it stays somewhat steady, or climbs more slowly. And this is with garbage collection turned on. With it turned off, there seems to be no barrier; memory usage keeps climbing steadily.
This isn't a huge deal, practically-speaking. But it bothers me. I want to know what is going on with the memory, if such "leaks" (?) occur in other standard gui objects the developer may have no fine control over, and if this is just a gap in my understanding of how things work.
The only thing I can think of is perhaps the app is storing a history of selected colours for whatever reason (and this history keeps growing), but this seems unlikely to me.
File it at bugreport.apple.com.
Leopard 10.5.8, XCode 3.1.1; using runModalForWindow to implement (what is intended to be) a high performance mouse tracking mechanism where I have to do real-time complex bitmap modifications.
The modal loop runs, the timer fires, the mouse tracks... but the performance is abysmal, and it gets worse and worse the longer the runloop goes on. Instead of catching mouse messages every pixel or so, I get them every 5... 10.... 20 seconds.
Instruments shows that the majority of the time during this growing response bottleneck is being spent in mach_msg_trap (and yes, I have the perspective set to the running app), so the impression I am under is that it "thinks" it doesn't have any work to do, despite the fact that I'm dragging the mouse around with the button held down like a crazy person. There are no memory leaks showing up, and in my 8-core 2.8 GHZ machine, there's almost no CPU activity going on.
Again, the app is not spending much time in my code... so it's not a performance problem of mine. I've probably configured something wrong, or failed to configure it at all, or am simply approaching the whole idea wrong -- but I sure would appreciate some insight here. As it stands now, the dispatch of mouse messages and timer messages is absolutely unacceptable. You couldn't implement a crayon drawing program for someone immersed in cold molasses with the response times I'm getting.
EDIT: Some additional info: doesn't happen on my 10.5.8 macbook pro. Just the 8--core, 6-display Mac Pro. I tried taking the display code for the croprect in drawrect out, replaced it with an NSLog()... still drags on issuing mouse updates. Also tried rebooting and running without the usual complement of apps running. And with mirrored displays. No difference.
Imagine dragging a brush across the screen; at first, is paints smoothly, then gaps appear between brush placements, then they get larger, and this goes on until you're only getting one brush placement every 10 seconds. That's how this acts. Using NSlog() and various other tracking methods, I've determined that it is at least at the highest level occurring because the mouseDragged events slow down to a trickle. The question in a nutshell is, why would that happen?
Anyone?
OK, isolated it -- the problem comes from my Wacom Tablet mouse. Plug in a regular optical mouse, and everything runs great. Same thing on my Macbook pro, using the trackpad. Works fine.
The tablet is a Wacom Intuos 4 with the stock drivers as of January 2011. I'm going over to the Wacom site and reporting this next.
What a nightmare that was. I have spent over 100 hours on this, thinking I'd hosed some subtlety in the app handling, drawing, etc. Sheesh.
I'm having strange effects with my app. I implemented my own PDF viewer. It shows ONE page at a time. Using Instruments Activity Monitor I see that my real memory is constantly at around 50MB.
After switching pages forth and back a couple of times I receive a memory warning level 0.
I do my best to react on it and sacrifice the low-res background image I'm rendering first to show something until CATiledLayer catches up.
Does not help. A few pages later I get memory warning level 1 and level 2 and after a few more pages my app gets killed with reason "9". Memory NEVER goes above 50MB!
Why do I get those warnings in the first place? There IS enough memory available.
This is happening on on iPad running iOS 4.3.
I don't think there's anything mysterious going on here -- which I'm sure is not what you wanted to hear. There are no absolute figures of "safe" amounts of memory to use. The rule is: when the OS tells you you're using too much, use less. It will jettison background processes first and in preference to your foreground app but there are still limits.
In the "olden days," you used to be lucky to get 20Mb. I'm sure you can safely get more than that on an iPad but, apparently, it's less than 50Mb.
You don't say how much memory you free by releasing the background image, but it seems that you need to be caching less data. You might also want to check Leaks (also in Instruments) to make sure you're releasing the objects you think you are.