3 ms·
Right, the pointers would still be scanned by the GC, so we can't elliminate the cost of the GC, unless we completely turn it off (I think that is possible). B
by hsn915 4y ago
Right, the pointers would still be scanned by the GC, so we can't elliminate the cost of the GC, unless we completely turn it off (I think that is possible).
But the point of the arena allocator is to make allocations and deallocatins very fast. Say you want to allocate many small objects for a very short amount of time and then get rid of all of them. Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator.
- morelisp 4y ago> But the point of the arena allocator is to make allocations and deallocatins very fast... Doing it on an Arena would save a lot of computation that would be required in a typical heap allocator. Relative to a completely naive allocator yes, but relative to any other kind of pooling (e.g. Go's internal small object pools, or a `sync.Pool`, or just a `make([]T, 1000)`) the advantage of a bump allocator is marginal without the ability to avoid the mark overhead and actually throw it all out at once.