2 ms·
>> 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
by 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.