> RC languages do need to free memory used to hold the values later

It also has arena allocators, so you can group allocations that will be freed at a similar time. You don't need to walk through these to find them all and individually free them. Anything with a Drop impl (destructor) gets thrown on a list for that to be taken care of; then the arena's relatively few, large blocks get freed all at once.

I've used this in C++ to squeeze the last bit of performance out of a high-request-rate server. I haven't done it in Rust, but it's the same idea.

btw, little confused by this:

> [RC languages?] have to run expensive compaction and locking steps

Was this meant to refer to GC languages? I've never seen one that does compaction (we're talking about the same thing? moving all the memory allocations around to reduce fragmentation?) That's more of a GC language thing that e.g. Java does; it would require the language/runtime to be able to precisely spot pointers and be able to throw in a trap when one it's changing is dereferenced or to entirely stop the world first.

Well, there is boehm if you do want to take on that complexity. But no, I am referring to the book keeping operations that are done internal to the malloc and free calls. They are largely hidden from you as the user of the API, but you still have to pay for them in runtime.

I thought rust didn’t have any safe arena allocators, but that some people make them by tricking the system with indexes instead and such, though word was they might come soon https://news.ycombinator.com/item?id=33403324