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... 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
|