Memory Usage just keeps on growing...

Blitz3D Forums/Blitz3D Programming/Memory Usage just keeps on growing...

Fry Crayola(Posted 2005) [#1]
I just noticed this today. Half an hour ago.

As I said in my other thread, I've got a 2D GUI up and running. Just now I noticed that with every single button press, the memory used by the program (as seen in Task Manager) grows. By almost a megabyte.

I can't understand why. One whole MB?

Irritatingly, the code is long and complex and so I can't post it here. What that button does is store the current information to the relevant place in a memory bank, switch to a new type of information and refresh that and a search panel. I can't work out where an extra MB is coming into play, and I know without the code I can't expect much help...

But a few pointers or tips on what sort of thing to look out for would be great.


GfK(Posted 2005) [#2]
Your first port of call should be to add some debug code to count how many objects are in each of your Type collections.

If that doesn't turn up anything, then check that you aren't loading/copying images and forgetting to free them when you're done.


Fry Crayola(Posted 2005) [#3]
The second one would be the first thing I would think of, but earlier code doesn't have the megabyte problem (though it does rise about 10K each time) despite not having had...

Ah. Wait. You're probably (although that's better read as hopefully) spot on there. When I flicked from using Text commands to using bitmap fonts, that's a lot of new images created that definitely aren't being freed. I think.

They're all local variables for the image handles. I guess I presumed that when they're discarded at the end of a function (they are, aren't they?) the same would happen to the images. Foolish logic and it's better to make sure they're freed up.

Suddenly my day is twice as bright.


Beaker(Posted 2005) [#4]
In Blitz3D images (and other media, banks etc) are never free'd automagically.


Fry Crayola(Posted 2005) [#5]
Automagically sounds cool.

Problem solved then. Each frame, every character has its own image. Sure, it's about 16x6, 24-bit colour making 288 bytes per character. It adds up over time, that's for sure.

I'll hopefully get that code changed tonight, let you know the findings. There's probably some other things that need cleaned up too.


Fry Crayola(Posted 2005) [#6]
That's it! Thanks guys, massive help there, really cheered me up.

When I added the following two lines to the GUI_text function (which displays text using a bitmap font):

FreeImage charImage
FreeImage colourImage

instead of increasing the memory 1MB it increases about 30KB - due to other processes.

With those cleaned up, things will really be the way they should be.


sswift(Posted 2005) [#7]
That's not my GUI system you're using is it? If there's a bug in my system I'd like to know about it. :-)


Fry Crayola(Posted 2005) [#8]
Nah, I wrote it myself. Part of me likes to have control over that aspect, and it's a good learning experience.

In truth, it's not a bad GUI and can be easily ported to BlitzMax when the time is right. It just has a few bugs - this being a particularly serious one. There's a few other small issues - I can't cut and paste (I'd like to be able to from outside the program), you can't move the cursor in my edit boxes or highlight text, and scrollbars aren't perfect. But it's not bad for a beta.


Clarks(Posted 2005) [#9]
One other thing. Dont forget that all blitz types are pointers so if you create one in a function thats just needed for the life of the function make sure and delete it. Blitz types take up 20 or 24 bytes default.


Fry Crayola(Posted 2005) [#10]
Good advice that. I never got too much time to tweak my code yesterday beyond the bitmap text function, but I was going to experiment with that. Some of my types would take up a quite hefty amount, in one case almost 1KB.

Just so I know, what about the standard types - integer, floating and string - do they get automatically deleted? I assume so, there appears to be no manual command for it.


Clarks(Posted 2005) [#11]
yes they do