A thought provoking older article by Steve Yegge that many I talk to haven't seen. It discusses styles of programming from the perspective of memory allocation.
I think allocation is a discussion worth continuing. It's so intrinsic to the in-the-large error rates - overcomplicate the data allocation picture, and you end up writing more, slower, and buggier code, but only some time after you made the mistake. Any solution you can name only captures a fragment of the problem.
Not a bad article but it misses a style that used to be (and still is, depending on where you look) common on game development: Arena based allocation.
Use lots of arenas. A per frame arena, a per level arena, each subsystem gets its own arena... etc. Shove anything that would be in a dynamic array into ring buffer, unless you can spare the holes in the arena (for per-frame stuff you usually can), of fill it as you allocate. Anything that has a more complicated lifetime than this either gets shoved into a free list or a pool.
And then thats it. Takes a little getting used to (mainly because dynamic arrays become a kind of bad idea) but once you're used to it you really never spend much time worrying about memory management. Caller vs callee free? Neither, it lives in the arena (etc).
It's also extremely fast, as arenas are more or less the cheapest memory allocation strategy, and you can very easily bound the memory usage of your program (needed in game dev a lot, for min requirements), since its patterns are so predictable.
Not sure how well it would translate to other areas... Lack of strings in game dev probably make this much more feasible that it might otherwise be.
6 comments
[ 6.6 ms ] story [ 23.4 ms ] threadUse lots of arenas. A per frame arena, a per level arena, each subsystem gets its own arena... etc. Shove anything that would be in a dynamic array into ring buffer, unless you can spare the holes in the arena (for per-frame stuff you usually can), of fill it as you allocate. Anything that has a more complicated lifetime than this either gets shoved into a free list or a pool.
And then thats it. Takes a little getting used to (mainly because dynamic arrays become a kind of bad idea) but once you're used to it you really never spend much time worrying about memory management. Caller vs callee free? Neither, it lives in the arena (etc).
It's also extremely fast, as arenas are more or less the cheapest memory allocation strategy, and you can very easily bound the memory usage of your program (needed in game dev a lot, for min requirements), since its patterns are so predictable.
Not sure how well it would translate to other areas... Lack of strings in game dev probably make this much more feasible that it might otherwise be.