Mastodon Feed
dysfun@treehouse.systems ("gaytabase") wrote:
why do i say we're onto a loss of memory efficiency by using a gc? because a 1.3x working set heap is probably quite tight and that's already wasting 30%, even assuming everything else is perfect. more realistic would be 1.5-2x for most apps i think.
of course we don't usually think about the bookkeeping overheads of malloc when we work with non-gc'd memory. they're not free. even assuming our malloc refuses allocations larger than 4gb (not entirely unreasonable tbqh), that's still a 32 bit size to store for it, even pretending we won't have other overheads (lol).
most modern allocators use size classes. we're disincentivised to use size classes for a gc because it means we're not filling blocks as often and we can't relocate different sizes into the same block to save space.
anyway i suspect that the memory overheads of allocators are not in practice wildly different from the memory overheads of GCs, albeit arranged somewhat differently.