Re: [GD-Consoles] Memory...
Brought to you by:
vexxed72
From: <phi...@pl...> - 2002-07-08 18:25:11
|
Memory pools are your friend. Also, avoid allocating / freeing anything during runtime as fragmentation is a bitch, and you don't have the virtual memory escape route any more. Seriously, the hardest thing about console game memory management, is that you actually have to think about it. Cheers, Phil "Mickael Pointier" <mpo...@ed...> To: <gam...@li...> Sent by: cc: gam...@li...urc Subject: Re: [GD-Consoles] Memory... eforge.net 07/08/2002 01:37 AM > Hi! > I would like to start my new engine using console friendly data structures > and memory handling. > Can someone help me with any tip? What allocation schemes do you use? > A large buffer that is handled like a stack? Or you can use, without > problems, lots of new/delete? > I would like to implement a new/delete handler to track all memory > allocations but in this way all memory should be dynamically allocated... > (not a good idea for consoles I fear). I would say that considering the small amount of memory we have on console, you cannot really afford to loose memory for trivial things. So instead of having a lot of small new/deletes (each one coming with some memory overhead: block chaining information...), you should instead allocate large chunks of memory, and use placement new (if using C++) in those blocs. The end result will be a gain in speed (during allocation and deallocation phase), and a gain in memory if you manage to allocate exactly what you need. Mickael Pointier ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Oh, it's good to be a geek. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-consoles mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-consoles Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=553 |