[dgb23]

I like the part about memory management. Arenas are so simple.

In the (toy) web server I'm writing I initially also started with arenas. However I quickly realized that I don't actually need to grow and shrink memory at all.

Currently I'm simply allocating the memory I need up front then slice it up into pieces for every module.

When we're programming, we often pretend like we could be needing arbitrary amounts of memory, but that's not necessarily the case.

Many things actually have very clear limits. For the rest one can often define them. And if you enumerate those, you know how much memory you will need.

It is fun to think about and define those limits up front. It builds a lot of confidence and promotes a healthy frugality.

[TillE]

Right, I'm always annoyed when people talk about how std::vector has terrible performance (especially for games), which it certainly does if you just start with an empty vector with no memory reserved and append a few thousand items.

But it is very frequently possible to find the actual maximum you will need, allocate that upfront, and everything's great.

[dgb23]

Coincidentally that's how I started thinking about limits and allocating everything up front. I wanted to try out arena allocation, with one arena per http request (and one for the entire lifetime).

But when I realized that if I wouldn't allocate a large enough backing array (capacity) then memory would grow by n+(n+1)+(n+2)... every time I allocate on the arena during a request.

Now you're right that this is not necessarily a problem. But this is a side project that I just write in order to learn and explore stuff.

So I thought I would need to figure out a static capacity and was thinking about how to go about this. Then I realized I don't need a data structure that grows, but only a slice of a static memory region, which then means I don't need an arena (which can arbitrarily grow) in the first place.

Now I'm exploring all kinds of things that a web server does and where I would normally use a dynamically growable data structure. Like parsing JSON, form parameters, HTTP headers etc. And I can find natural or self imposed limits for all of those things.

For me, the most interesting thing about this isn't even performance. It's the mere fact that you _can_ figure out and design those limits. And the resulting code doesn't become complicated, but looks much simpler than I would have guessed. I really like the exactness of it all and how it changes the way I think about these things.

[i80and]

The TigerBeetle database is built this way, and I kind of love the concept https://tigerbeetle.com/blog/a-database-without-dynamic-memo...