LÖVE

I'm using: To calculate the size of the heap.

If I press nothing and just watch the heap size it will increase and decrease by around 200MB regularly. I'm using lots of large image files which I suspect is causing the large memory footprint (Task Manager says the game is using 534,224K of RAM), but I can't figure out why the heap is fluctuating by so much and so often. As far as I know I'm using the memory correctly. I load all of the images and music in love.load so loading only happens once. When the current animation is changed it should be changing to an already loaded animation and not destroying the previous animation so it can be reused.

I hope the code is easy enough to understand, but if it isn't let me know and I'll try to explain. The game is playable, but not ready or fun. The only key that is a must know is 'm' to pause the music.

Thank you.

Trevor wrote: If I press nothing and just watch the heap size it will increase and decrease by around 200MB regularly.

That's just how the Lua garbage collector works. It will let garbage accumulate up to a certain point, then clean up, and then the whole process starts again. This is not a memory leak.

You can confirm this by adding "collectgarbage()" as the first line of love.update(), this will force full garbage collection all the time. Then your memory use will remain constant (I have tried it).

I'm starting to think the problem is that I've misunderstood the value returned by collectgarbage("count"). Now I think my game is only using a few hundred kilobytes not a few hundred megabytes.

According to Lua 5.1 Reference
"LUA_GCCOUNT: returns the current amount of memory (in Kbytes) in use by Lua."

If it is using ~300Kb then why is ~540MB of RAM being used according to Task Manager? I'm on Windows 7 64bit Pro w/ SP1.

I hope you are right hexenhammer, but I have trouble with the idea of hundreds of megabytes of garbage being generated while the game is idle every few minutes.

Really strange, im getting 200Mb in ubuntu 12.10. I start commenting line out, and it appears it has to do something with the Fighter:load method, cause by loading only one fighter, i get 100 Mb, and i get 8Mb by loading no fighters.

Perhaps, what is happening is that hundreds of megabytes of ram are being used to hold the decompressed pngs, but only a few hundred kilobytes are being used by the Lua heap which means it is fluctuating by hundreds of kilobytes, not megabytes like I thought.

Trevor wrote:I'm starting to think the problem is that I've misunderstood the value returned by collectgarbage("count"). Now I think my game is only using a few hundred kilobytes not a few hundred megabytes.

According to Lua 5.1 Reference
"LUA_GCCOUNT: returns the current amount of memory (in Kbytes) in use by Lua."

If it is using ~300Kb then why is ~540MB of RAM being used according to Task Manager? I'm on Windows 7 64bit Pro w/ SP1.

I hope you are right hexenhammer, but I have trouble with the idea of hundreds of megabytes of garbage being generated while the game is idle every few minutes.

it is using a few hundred megabytes: as mentioned, collectgarbage returns KB and you have several hundred thousand of that

memory use increases about .8-1.5 megs/s between sweeps so that's not too horrific (most of which is probably temporary strings created during runtime)

Trevor wrote:Perhaps, what is happening is that hundreds of megabytes of ram are being used to hold the decompressed pngs, but only a few hundred kilobytes are being used by the Lua heap which means it is fluctuating by hundreds of kilobytes, not megabytes like I thought.

Indeed. A single 2048x512 png will use at least 4MB of memory as ImageData, and an additional 4MB of video memory as a graphics image. collectgarbage("count") doesn't count (most of) the space taken up by LÖVE's data objects.

Thank you slime! I'm glad that this is cleared up. However, I feel a little embarrassed that my huge memory leak was actually a few hundred kilobytes. Thank you Hexenhammer, master both, and Xgoff for also helping to resolve this misunderstanding.