Comment by lunar_mycroft
1 hour ago
Disclaimer at the start: Rust is my favorite language, this very much isn't an attack on Rust.
> Dropping vecs that contain strings does not make any Rust code in the real world slow. You would need to have a vec containing billions of strings, occupying several gigs of memory
I actually had a hobby project where that became very noticeable/too slow for my requirements at around 800k Strings, so several orders of magnitude less than your estimate. Switching to a solution that freed all the memory at once predictably made it run effectively instantly.
> And for extreme cases like that, you can simply use arenas
I think this is a fundamentally flawed way of thinking about things. Yes, each individual string allocation and drop isn't going to cost much, but in combinations with all the other similar decisions you're likely making if you think this way, plus the decisions of library authors, etc, it can add up even if strings specifically aren't a major problem. Avoiding pessimization by default instead of only when you can't ignore them any more is a good habit to be in.
Arenas aren't a free lunch either. You need a specific sort of memory access pattern, where large, conceptually related chunks of memory are being rapidly and predictably reclaimed, and if you don't have such a pattern then arenas are ceremony for no benefit. And the performance tradeoff is that you end up using more total memory than RAII because you're no longer eagerly reclaiming memory the moment it stops being used, but purposefully delaying your frees so that you can batch-reclaim it all at once. There are many cases where this makes sense, which, to reiterate, is why crates like bumpalo exist, which work gloriously well with Rust's lifetime system.