Gradual Slow down, but no visible leaks

Forums Programming cocos2d support (graphics engine) Gradual Slow down, but no visible leaks

This topic contains 7 replies, has 2 voices, and was last updated by  blackmouth 2 years, 2 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
Author Posts
Author Posts
January 25, 2012 at 1:24 am #238674

indy2005
@indy2005

Hi,

I am not much of an expert in using Instruments, but my game which uses CCMask amongst other things to simulate bullet holes in sprites, starts off all well and good at 60 FPS, but gradually degrades to about 30 FPS.

I found a few memory leaks, and bad retains and got rid of them. Instruments now shows more or less a constant 15.4 Mb of active memory use, and the number of live objects seems to be steady around 21,000…i.e I think I have got rid of most of the memory leak issues. Unless the Sprite property of the Render Texture is somehow being retained, but I would imagine seeing total memory increase above 15.5 Mb over time.

And 1522 Immutable Strings in memory…whats that all about!?

Its a release build.

An advice appreciated, as once I sorted my leaks out…I thought things would improve.

Its only a whack a mole…actions throw things in the air, you tap them, and a mask cuts a hole in the sprite texture…few particles, but nothing is retained now beyond adding as a child to the parent node.

Regards

i

January 26, 2012 at 8:21 am #363337

indy2005
@indy2005

now i have moved to using Object Pools this seems to be working better, but I don’t know why allocating a few sprites on the fly would slowly the game down…I was releasing them all, and only allocating a few sprites every few seconds? I would have through an iPhone 4 could handle creating the occasional object!

January 26, 2012 at 8:37 am #363338

blackmouth
Participant
@blackmouth

I’ve lately started using the allocations instrument and pressing the mark heap button at intervals you would think the problem happens. Say you start a new scene, click the mark heap button, then repeat the process. The chunks of stuff allocated should eventually go back down to zero, if it doesn’t then you can go back and look at what’s still hanging around.

Also, you can check to see if that sprite is released by printing something in the dealloc method.

http://useyourloaf.com/blog/2011/3/8/using-heapshots-to-find-abandoned-memory.html

http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

January 26, 2012 at 6:54 pm #363339

indy2005
@indy2005

Thanks…have been sing both techniques, slthough I am never sure what t subsequent heap snapshots show…is it just the new objects created since the last heap snapshot?

January 26, 2012 at 10:05 pm #363340

indy2005
@indy2005

this seems to look reasonable….

http://dl.dropbox.com/u/33985771/instuments.jpg

January 26, 2012 at 10:54 pm #363341

blackmouth
Participant
@blackmouth

Yea that looks fine. I would use time profiler now and see what’s taking up so much processing time.

January 26, 2012 at 11:20 pm #363342

indy2005
@indy2005

still not quite sure how to interpret the heaps, and what the <non-object> types are.

When you baseline, and then you subsequently take a heap snapshot, do you only see the objects allocated from that heap snapshot onwards…i.e. the 461 I can see in Heapshot 2….they must still be in memory…but don’t form part of snaphot 3? Snapshot 3 had some living objects which thankfully reduced to zero….

Time profiler…will have a look, thanks for the help..Instruments is actually pretty darn cool.

Regards

i

January 27, 2012 at 12:13 am #363343

blackmouth
Participant
@blackmouth

Yes you want to create a baseline, say something like a scene replacement, then take heapshots when you reach that point again and verify the previous heap reduces to zero.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.