I don't know about more error prone. Benchmarks completely aside, freeing a batch of stuff you've allocated in a single place makes it easier to manage memory. I think it should be preferred wherever it's an option for that reason most of all. The "killer app" is something like an arena allocator that lives for the duration of an HTTP request.

I meant to suggest using arena allocation for everything and not even using a malloc style allocator. Just getting memory via memmap at program start and then using arenas for everything after that.

It makes it much easier to avoid lifetime mistakes in my experience.

Using arena allocation also makes me think more about how much memory I am using and how much memory I should be using etc.

It is hard to benchmark it against just using a global allocator because it is a structural change to the whole codebase.

i think the reason is more that arena's let you manage lifetimes in groups instead of pointer chasing. if you have to manually manage memory, it's eaiser to manage a small number of arena objects instead of a large number of individual objects.

eg https://www.dgtlgrove.com/p/untangling-lifetimes-the-arena-a...

that being said, it's even easier to not manage any lifetimes at all :)

although i suppose some will say that you still manage lifetimes in rust, you just have full support from the compiler to make sure you do it right. that seems better to me than relying on simplification to ensure you don't make mistakes.