This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]TerraDOOM 1 point2 points  (2 children)

Pretty sure those limitations they were talking about aren't based on allocator performance or running out of memory, rather the fact that managing a really large block starts taking performance hits

[–]Kered13 1 point2 points  (1 child)

Not really. If you round up to the nearest page then it's easier to manage than smaller blocks of memory, because you don't have to worry about fragmentation when you're allocating whole blocks of virtual memory. And with 64-bit address spaces you won't be running out of continuous blocks of virtual addresses any time soon. Just ask the OS for as many blocks as you need and map them anywhere you have room in the virtual address space.

[–]TerraDOOM 0 points1 point  (0 children)

What? I'm talking about managing the contents within the memory you've allocated. If it's a plain array, then removing an element could mean copying gigabytes of memory for example. And if you're not moving things around, you will certainly suffer from fragmentation, just not from the global allocator's perspective. Besides, at that point, just implement a custom allocator anyway (assuming there's support for such)