#141357 - keldon - Mon Sep 24, 2007 2:31 pm
Dynamic allocation scenario:
- there are 16 blocks of memory
- you initially allocate 3 for some random reason, but the 3 blocks will remain allocated
- your program is like a web page, in that memory allocated for each section will be completely thrown away with each transition
- because of this you know that if you allocate 10 blocks that you will deallocate 10 blocks when you are done with that webpage
Would it be beneficial to create custom allocation methods or would it be safe to use new/malloc and delete/free even if you don't deallocate in the same/reverse order as you allocate?
I would expect it to be fine, I mean when I wrote memory allocation methods it would be fine, but mine were written for correctness and not speed.
#141365 - gmiller - Mon Sep 24, 2007 5:50 pm
Depending on how you manage your allocations there can be issues that "malloc/new/free/delete" can be slow depending on how you manage the information. The reason not to use the standard routines can be speed, lots of games allocate a chunk of "heap" and then manage the chunk themselves. There can be reasons to allocate extra data at the beginning to save pointers to internal structures so the management can be done faster. Every choice has good/bad associated with it so there will be trade offs no matter what.
#141370 - sajiimori - Mon Sep 24, 2007 7:50 pm
If there are a few permenent allocations at the beginning, and the rest is like a frame heap (where you never free anything, until it's all freed at once), then you won't have any fragmentation.
#141405 - tepples - Tue Sep 25, 2007 2:02 am
| sajiimori wrote: |
| If there are a few permenent allocations at the beginning, and the rest is like a frame heap (where you never free anything, until it's all freed at once), then you won't have any fragmentation. |
What would be needed for the destructors of objects within this frame heap to get called properly, releasing any other resources outside the frame heap (e.g. VRAM) that they may own? Or is the RAII model considered overkill on a DS or smaller?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#141408 - DekuTree64 - Tue Sep 25, 2007 2:17 am
| tepples wrote: |
| What would be needed for the destructors of objects within this frame heap to get called properly, releasing any other resources outside the frame heap (e.g. VRAM) that they may own? Or is the RAII model considered overkill on a DS or smaller? |
If you need to create and destroy things within the frame heap, you could use manually managed "slots" for the objects, and placement new into them. Otherwise deleting doesn't seem like such a good idea, since that implies that you'll be creating new objects too, which would perpetually grow the heap.
I definitely wouldn't consider RAII overkill on the DS.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#141413 - tepples - Tue Sep 25, 2007 2:37 am
| DekuTree64 wrote: |
| If you need to create and destroy things within the frame heap, you could use manually managed "slots" for the objects, and placement new into them. |
I seem to remember something like that explained somewhere in the first half of Effective C++ by Scott Meyers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#141475 - sajiimori - Tue Sep 25, 2007 11:58 pm
RAII FTW. :)
If you design your code specifically for a frame heap, you could override global new/delete and have them run linked lists through allocations of particular sizes.
For instance, if you try to allocate 16 bytes, operator 'new' would look at the '16 byte' linked list and pop the first free element, or else append a new one to the end of the frame heap.
That's basically a generalization of having pools for particular object types. When you think about it, the type of object doesn't matter -- only the size.
No fragmentation, but potentially a lot of waste from unused allocations. Probably more predictable behavior than a standard heap. Very fast in the average case. YMMV.
#141495 - keldon - Wed Sep 26, 2007 7:48 am
Well I overrid the classes new constructor (of certain objects) to allocate memory from a simple pool since all of those classes only exist for a certain use. The pool just keeps track using a offset pointer that it makes sure is always aligned.