4 ms·
> If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem)
by adwn 4y ago
> If you're going to do that, would you not be better saving all that time and code bloat (it's code you wrote that doesn't contribute to solving your problem) by just using a garbage collector from the outset?
An arena-based allocator will run circles round GC and malloc: no need for tracing or bookkeeping, just one allocation and one deallocation for any number of objects created (or, at least, the ratio of created objects to memory allocations is very high). And with Rust, the compiler will give you an error message if you try to hold on to an object in an arena you're trying to deallocate.
- CraigJPerry 4y ago>> An arena-based allocator will run circles round GC and malloc Where does the overhead of copying the surviving objects over to the new arena as you drop the old one factor into this? Or maybe you could own more non-problem-solving code and permit cycling of one arena? Could get tricky if you want to rely on destructors? The ratio of lines of code written to solve the problem vs written to shave yaks is getting lower still here.
- adwn 4y agoYou're misunderstanding the purpose of an arena allocator: It's only for relatively short-lived objects which are all released at once; there's (typically) no transfer of objects to a new arena. This isn't as uncommon as it might seem – for example, auxilliary data which is created during the execution of an algorithm, and which isn't needed anymore once the algorithm has finished, or per-frame data in a computer game. > Or maybe you could own more non-problem-solving code [...] You know, sometimes performance is the problem, and code which improves performance does solve that problem.