12-19-07 - 5

Back in the old C days, to do fast allocations I would use various manual allocators. A standard one was a simple pool with freelist. These days I usually just replace the global allocator with some fancy thingy and let it go. I was looking over some ancient code today (the Genesis curved surfaces with view dependent tesselation, that was fun), and it reminded me of some advantages of the old custom allocator scheme. (I'm talking about an allocator which is used only for one type of object; some tree node for example)

Obviously you have the advantage of being able to custom design the allocator for your usage pattern to optimize speed. That's not a huge edge these days, but there are things you can't do with a normal allocator :

1. Just tossing the whole object. When your object is some complex tree, you can do all these little allocations, then when you're done with it you can just reset the whole pool, you don't have to walk the tree. This is not so much just a speed win as it is nice for simplicity and code reduction, and when you're in the destruction phase you don't have to worry about tracking pointers or who owns the pointers or anything.

2. Getting a linear memory iteration on the nodes. This is the really cool thing. So you build up this whole tree using some complex logic. Now you want to do something where you have to visit every node. If you descend the tree it will be in random memory order and be totally horrible for performance. What you really want is to walk the nodes in linear memory order. Of course you could maintain this as a side structure with a normal allocator, but if you have a pool allocator, the linear hunks of nodes are right there. You just get the memory blocks from the allocator in iterate over them.

3. Other nice accounting things, like easily being able to ask your allocator how many are allocated and have it give you the answer for just this exact type of object.

No comments:

old rants