Memory Allocation/Deallocation Bottleneck?

Question

How much of a bottleneck is memory allocation/deallocation in typical real-world programs? Answers from any type of program where performance typically matters are welcome.

Answer 1

Pretty much all of you are off base if you are talking about the Microsoft heap. Syncronization is effortlessly handled as is fragmentation.

The current perferrred heap is the LFH, (LOW FRAGMENTATION HEAP), it is default in vista+ OS's and can be configured on XP, via gflag, with out much trouble

It is easy to avoid any locking/blocking/contention/bus-bandwitth issues and the lot with the

HEAP_NO_SERIALIZE

option during HeapAlloc or HeapCreate. This will allow you to create/use a heap without entering into an interlocked wait.

I would reccomend creating several heaps, with HeapCreate, and defining a macro, perhaps, mallocx(enum my_heaps_set, size_t);

would be fine, of course, you need realloc, free also to be setup as appropiate. If you want to get fancy, make free/realloc auto-detect which heap handle on it's own by evaluating the address of the pointer, or even adding some logic to allow malloc to identify which heap to use based on it's thread id, and building a heierarchy of per-thread heaps and shared global heap's/pools.

The Heap* api's are called internally by malloc/new.

Here's a nice article on some dynamic memory management issues, with some even nicer references. To instrument and analyze heap activity.