[jstimpfle]

> the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage.

I'm not quite sure, do you mean arenas are slower, and use more memory, compared to standard vector-style allocation (which does a lot of copying, iterator invalidation, and wastes like 0.25x memory on the average), or compared to individual malloc/free (which does a lot of book-keeping work and wastes book-keeping memory)?

[kibwen]

The difference between an arena allocator and RAII deallocation is that the latter is eager. This is the whole point: the problem that an arena allocator attempts to solve is to presume that fine-grained freeing is slow and thereby solve that by batch-deallocating a whole lot of things at once. But it will, be definition, end up using at least as much memory as an eager deallocation scheme, because the whole point is to not be eager, which means not immediately freeing memory even when you could. This is a fundamental tradeoff. I'm not sure what you mean by "vector-style allocation", but iterator invalidation et al is a non-sequitur for this discussion.

[jstimpfle]

Iterator invalidation is absolutely a huge deal for many datastructures in practice. From an ergonomic standpoint alone it makes a huge difference. 10 years ago I argued the opposite, but juggling indices simply is not fun. Replacing pointers with indices can be useful but it's not a good default.

You are also ignoring bookkeeping overhead and fragmentation that comes with individual allocation.

The important difference between arenas and RAII as far as I'm concerned is that the former allows exploitation of allocation patterns, like stack shaped allocations, which can reduce complexity in a meaningful way, requiring no cleanup code at all. RAII on the other hand does not give you that -- it is just a disciplined system to automate some code, but the complexity is still fully there, and a lot of constraints are put on the types and your internal organization in order for RAII to work.

Arenas are quite a good fit for frame memory in graphics programming, and they do not waste memory there if done right. On the contrary they probably save some, but that's not the point here. We're typically talking about a couple megs per frame at most, which is spare change.

Some people, like Ryan, have managed to apply arenas more widely, but personally I am more in favour of a varied mix, and don't mind a bunch of manual code either, but I definitely like to control allocation more closely compared to what e.g. malloc/free allow. I like to keep objects in their specific subsystems. I have written my own block allocator to do this. Now allocation does not show up anymore on my profile almost at all, it's <<< 1÷ of my CPU usage even though I recreate tens of thousands of objects per second. Also syscalls are ~zero as long as memory usage is roughly the same from frame to frame.

As I said elsewhere, performance and correctness/clean modelling always go hand in hand. The correct model must allow for the right level of performance, or else it's not the correct model.