garbage management
BlitzMax Forums/BlitzMax Beginners Area/garbage management
| ||
| Sorry to all if I re-open an old thread, but I need to have the a right solution. First of all, in the game I have some list and objects; some of them will be destroyed, other no. At the end of the level I destroy all the objects and clear all the list. Then run GCCollect to 'flush the mem'. Now, I'm thinking: can I put a GCCollect() in the main loop or this is 'dangerous'? It slowdown? GCCollet() runs immediately the garbage collector? I need to use the GCSetMode(manual) to obtain better result? What method do you use? Thanks in advance, but I think this is a point to clarify for all. |
| ||
| Might seema silly question but have you got a memory leak? I leave Bmax to do all garbage collection but keep an eye on memory allocation. I keep a high-watermark and, from one run to another, if it's excessive or jumps too much I check what I added for problems. The only advantage I can see (now) with manual GC is you know when it will be run (but not when memory will be reclaimed). If you want to go that route keep an eye on memory consumption and run gccollect during any spare cycles or when it's becoming a priority. |
| ||
| I don't think there is any good answer about when to use GCCollect. So I agree with Tony on this one. Just let the garbage collection be automatic. Later, if you suspect that performance could be better, you can try calling GCCollect in places where think it might help. |
| ||
| You can put a GCCollect into the mainloop But it is not needed. There is no real need to keep the RAM usage low if there is plenty of RAM, as it only makes the game slower (memory alloc dealloc isn't a that fast thing). |
| ||
| Many thanks to all, I was wonder if I made the 'right' things, and it's seem to be ok. My only worry is about the gfx memory: in the game after some levels I need to change the background graphics, so I null all the refer to the image_back and run GCcollect() and then I load the new level. On my test machine (8Mb vram shared - I know it's crap!) I got a memory error: it's probably due to 'out of videoram'. But as the background are the same size (640x480x32bit) is there a way to re-use the same chunk or vram or it's pure speculation? By the way: after destroying all my objects (and all the inner reference, timage pointer, tlink pointer and so on) I use ClearList and then I delete too the List (and then re-create them): I noticed a little increment in GCCollect() memory so I think it is a 'good' method, or no? |
| ||
| If the image was really destroyed, it shouldn't be there anymore. But for a "secure" way you could do a flip after the GCCollect and see if it helps. But you must have quite a strange graphics card ... Because 640x480 as TImage means 1024x1024 which normally won't work on such old cards at all (GeForce 3 or 4 at minimum when I remember correctly) and thats what is needed to have an image of that size (as 640 becomes 1024 and 480 becomes 512 -> max(1024,512) = 1024). To test if it is a VRAM thing you could load it as pixmap and draw the pixmap ... if it works then then it most likely might be VRAM thing. If not, then perhaps the system just is too low on memory or has a too small paging file. (because out of memory often comes up if the paging file can't be made larger either because manually fixed to that size or because the users have their C partition full of trash) |
| ||
| Thank for the info - the FLIP after the GCCollect is interesting... The Gfx card is a CyberBlade ai-something, it is a integrated for portable computer (Celeron 800 + 128Mb ram+ WinME). I know that it's not a 'normal' configuration today, but I use it as worst case possible: if the program runs on this, well, it should run on other (better) configuration. Thanks for info about paging & Hd space: I'm using computer with big ram&hd so this problem was out of my mind. |
| ||
| OK that system is a little crit ... or I should say anything before Win2k / WinXP is as the memory handling of Windows itself is fundamentally different (there is a good reason they *win98 / winme* aren't supported anymore). |
   |