On this msdn page, it says
The fewer objects allocated on the heap, the less work the garbage collector has to do. When you allocate objects, do not use rounded-up values that exceed your needs, such as allocating an array of 32 bytes when you need only 15 bytes.
Does anyone know why this recommendation is here (apart from the obvious – which I doubt is why they have this here)?
What’s the harm in allocating space rounded to a word boundary?
Does it have an effect on performance?
Rounding up allocations was a strategy in the olden days of unmanaged code, before sophisticated heap managers became available. It reduced the ill effects of heap fragmentation, having a bunch of small empty blocks in the heap that can’t be combined in a bigger one. And thus having the program terminate with OOM with lots of unused memory. There’s no point to it left today, the Windows low fragmentation heap solved the problem, albeit that it rounds up allocations as well. Up to a multiple of 8 for small allocations. Available since XP and turned on by default for Vista and up.
There’s no point to it when you have a garbage collector that can compact and get rid of the holes. You just give it more work to do, moving unused memory, without benefit.
Heap fragmentation is not a completely solved problem in managed code, the Large Object Heap can end up having empty holes that are hard to re-use. The LOH doesn’t get compacted, too much data to move. And rounding up allocations for objects larger than 80 kilobytes actually could still make sense. You’d only do that when a memory profiler shows you that you’ve got an LOH problem. At which point you should first consider moving to a 64-bit operating system.