Hacker News Reader

Comment by ozgrakkurt | Hacker News Reader

Would recommend learning how to use arena allocation. You would have patterns like:

fn run_query(alloc) {

   arena = init_arena(alloc);

   defer arena.deinit();

}

View on HN

Step zero of using arena allocation is to build realistic benchmarks so you can measure if it's worth the trouble in the first place. Standard allocators are incredibly good these days, and even plugging in mimalloc or jemalloc will be much less work, and much less error prone.

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.

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 respectfully disagree. The technique has its place, and I use it once in a while, but whether it makes a positive difference for performance is highly sensitive to a number of factors.

For example, bump style allocators allocate very quickly, but at the cost of higher memory usage and therefore sometimes worse cache locality.

The only way to know is to actually measure.

You disagree with a point I never made. My point is that they enable easier memory management, regardless of whether they're more performant. I really don't understand how that point didn't get across. You must simply not have read what you responded to.

You said

> I think it should be preferred wherever it's an option for that reason most of all.

And that’s far too broad in my opinion.

Sure, if you’re writing in a language that makes memory management difficult, like C or Zig, that might be worth it, but arena allocators apply to many other languages too.

> You said

Yes, which you didn't respond to until now.

> And that’s far too broad in my opinion.

Similarly, it's far too broad to say that it's "much less error prone" to use a more general allocation strategy. Clearly we both make unspoken assumptions, but in the context of this discussion on Zig, where you initially responded to an example written in Zig, I think you actually understood what I meant.

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.

If this works for the programs you write, that’s great. It does preclude you from using many great data structures with potentially better performance - especially hash maps. Rehashing is pretty detrimental to most arena allocators you can think of.

It is pretty tough to figure out how to structure it and I’m not 100% on it.

But, you can use hashmaps fine. Just need to think about it and structure the program well for it.

It becomes clear once you do it a couple of times

Reply on news.ycombinator.com