What else would slow down my game after each cycle?

Solar2D General Questions/Discussion
#1

I use this

timer.performWithDelay(1, function() collectgarbage("collect") end)

to garbage collect at the beginning of my title screen. I then display

collectgarbage("count")

on the screen to show how much memory the game is using at that point.

In the simulator, I can have the game play itself for awhile and then return to the title screen. The memory is always a bit different depending upon how far it got playing itself, but it’s always just a bit up or down within a reasonable range.

But when I run on the iPad, it will play the first time through at normal speed, then each subsequent run gets a bit slower and slower. After four or so runs it’s in slow motion. The memory display is the same as the simulator, just a bit up or down each run but always within a reasonable range. Therefore, I know I don’t have a memory leak problem (if I had a memory leak, the number would always go up and never come back down).

So what in the heck else could be causing that? I do have three

Runtime:addEventListener("enterFrame", xxxxx)

listeners that run during the course of each run (one at a time… never two or three at once), but I also shut each of them down

Runtime:removeEventListener("enterFrame", xxxxx)

Are forgotten and always running listeners and memory leaks the only two things that could cause a game to slow down over time?

Any suggestions welcome!

Thanks…
[import]uid: 5540 topic_id: 25059 reply_id: 325059[/import]

#2

Have you tried without the garbage collection timer on the iPad? Might be a simple case of over engineering trying to clear everything up has actually created a problem. Lua has automatic garbage collection so if it works then overtime memory will be freed up anyway.

[import]uid: 33866 topic_id: 25059 reply_id: 101810[/import]

#3

Besides those two things the only objects that don’t clear themselves up easily are sounds. You can also have some endless transition or timer that you forgot about. What’s your memory usage? Usually anything above 1.5MB means trouble. [import]uid: 61899 topic_id: 25059 reply_id: 101812[/import]

#4

To add to this.

Why are you putting your garbage collection on a timer? If you’re printing your memory right after the timer call, there is a seriouslly good chance, even with the delay being 1/1000th of a second that the print statement will run before garbage collection even runs since the timer made that call asynchronous and probably in its own execution thread. In other words you are not waiting on garbage collection to finish before you print the value.

My first thought is that you’re not removing the Runtime enterFrame listeners. But lets say that you are.

Based on what you’re telling us, you are only checking your “Lua” memory. You are not checking your texture memory. Lua memory is usually just a couple of hundred Kilo bytes. Your texture memory is measured in Mega bytes (1024 KB). You need to print and monitor your texture memory because if you have a leak, its likely those large chunks of memory are going impact your app more than Lua’s memory.

As @CluelessIdeas said, there isn’t a good way to measure your sound usage and that can be a huge source of memory leaks.

If you’re on a Mac you will have a program called Instruments available to you. It has a couple of tools that are very useful for managing your memory usage: Leaks and Activity Monitor.

Activity monitor works much like the one on your Mac, but it monitors the activity on your tethered device. It will show you your apps current memory foot print as it runs. This shows you ALL memory in use: Lua, Texture, and non-tracked things like audio.

Leaks on the other hand gives you a timeline and watches for allocated memory loosing its reference. It also has an allocations graph that shows the memory growing as well. To use Leaks you have to build your app using a Development Profile not an AdHoc one which maintains the debugging information.

o Tether your device.
o Use Xcode organizer to add your development profiled app to your device.
o Launch instruments and pick leaks
o Find your app in the drop down for “Targets” and hit the record button.
o It will launch your app on your device for you.
o Play your game and watch the graphs for problems.

Your app will run VERY VERY slowly while this is happening and the location information on where leaks happen is useless since the corona names for things are not maintained. But it will give you a feel for where problems are.

I’m betting that you’re not removing a runtime listener that you think you are though. [import]uid: 19626 topic_id: 25059 reply_id: 101869[/import]

#5

No, I hadn’t thought of that! As soon as I got to the point where I started to check for memory leaks, I just immediately jumped on forcing garbage collection. Thanks for the advice… I’ll try it without forcing it! [import]uid: 5540 topic_id: 25059 reply_id: 101902[/import]

#6

Excellent, I hadn’t even thought about sound! Thanks… I’ll check that next… [import]uid: 5540 topic_id: 25059 reply_id: 101903[/import]

#7

I stole the garbage collection on a timer bit from here:

http://jonbeebe.tumblr.com/post/2090082695/faster-garbage-collection-with-corona

Since everyone knows more than I do, I tend to “borrow” such ideas whenever I find them!

I didn’t mention it, but I am printing the texture memory also. The results of that are rock solid steady, so I eliminated that as an issue.

Thanks for the advice on using “Instruments”… I’ll give that a try! [import]uid: 5540 topic_id: 25059 reply_id: 101907[/import]