The problem with the Low-Fragmentation Heap is that the granularity can be excessive for very small blocks. For example, for a 10 bytes structure, 16 bytes are reserved from the system (an increase of 60%!). This was enough for me to refuse using them but I would like to see stats about them.

Have you tried them?

>Although the implementation provided by Visual Studio have been >improved a lot (last version tested: Visual Studio 2005) it is not >especially good at the points described before.

What do you think about Low Fragmentation Heap mechanism?

Ok, continuing down this path, what is a dynamic memory allocation? I know you probably mean: passing an allocation request to the OS. Because, whatever way you put it, dynamic memory allocations are being performed whether you use pools or whether you use the default malloc implementation. There aren’t many differences except for the fact that an allocation at the OS level may be slower in some implementations. The Windows allocator also has specific pool-like structures to optimize for allocations of certain sizes smaller than a certain treshold. Conceptually, there isn’t a much of a difference. Even more, many OS allocators will likely be more efficient than a common implementation. I have also seen some that operate really bad under some circumstances. So, what does “not doing dynamic memory allocations” precisely mean?

I wonder whether you are not looking at this problem from the wrong angle. Personally I believe that many people do. It sometimes seems that pools are generally looked at to be a very good solution to avoiding fragmentation, but the paper I mentioned proves that global solutions are superior to local solutions. So I wonder how you will look at this problem after reading this paper (reading the first 30/40 pages should do).

Yes, the phrase ‘the best memory management is doing no memory management at all’ is not very correct. I agree with you. My idea was to express that the best very memory management is doing no dynamic allocation at all. Obviously that is hard to achieve without a good memory management architecture. I will fix it in the next version of the article.

About the pools. Most implementations of pools allows some kind of granularity control. For example, your pool of particles can be a linked list of memory chunks. Imagine, you choose the granularity at 32. In that case your number of allocated particles will always be a multiple of 32. But a map with 200 particles will allocate 7 chunks for the pool and the map with 2000 particles will allocate 63 chunks.

Thanks for commenting and thanks for that paper recommendation.

I am not sure if I agree on all parts of your article. You say: ‘the best memory management is doing no memory management at all’. This is derived from the performance optimization rule, but it doesn’t necessary need to work for memory management. I am not sure what “doing no memory management al all” means. In memory management it is harder to create allocators that are space efficient than time-efficient (creating an O(1) allocator is peanuts). Doing no memory management at all can often translate to (what you are also saying later in the article): avoid dynamic memory allocations. If you are trying to do so, this means that you will need to allocate up front or in pools. In many ways this is not space efficient at all. Pools are often thought of as good solutions to avoid fragmentation, but in fact the internal fragmentation is much worse than the external fragmentation. You say that internal fragmentation is insignificant at full loads. Sure, but the problem is generally that the pools are often not full. They need to be large enough for worse-cased scenarios. Using pools you design your application for worse case scenario loads. They cannot be load-balanced. To give an example: you have a memory pool that holds your particles. In some levels you have many particles and in some you have only a few. The pool size needs to be big enough to hold the particles in the worst-case level. Some levels that contain only a few particles may have very large textures, but due to the memory pool structure you cannot load-balance. In most of the levels you have wasted a large part of your memory. A decent general purpose allocator like the ones you suggested would have been much more efficient. You might say that you would setting a pools size per level would solve this problem, but in fact you are only moving it to a smaller scope. And, this process is very cumbersome and error-prone. To conclude, this example shows that “doing no memory management at all” is not entirely true. Doing memory management, but properly, would have been better.

PROs: high performance. And if you get your title running it will keep on running. That is important on game consoles. CON: you are almost certain to be wasting a lot of memory.

I would recommend to everybody to read the paper: “Dynamic storage allocation, a survey and critical review”. It is an essential read prior to doing anything with memory management. Google it

Interesting article and interesting blog

I have a question for you about the StackWalk64… Yes, it is slow but not using it generates incorrect stack traces in release (due to the FPO). Do you switch dinamically to StackWalk64 when RtlCaptureStackBackTrace fails?