I found myself reading this article at StackOverflow when I encountered a problem in our code with a variable that we'd allocated using boost::fast_pool_allocator. It turned out that the problem was in our own code so the boost connection was just a red herring but it got me wondering....
One of the commentators in that article mentions that performance-wise, boost::fast_pool_allocator isn't particularly fast and this got me wondering about how the Windows heap manager allocates memory. If I malloc (say) 3 x chars, surely the heap manager doesn't examine the heap each time to find the next available free byte? I'd imagine that when I first ask for a char, it allocates some kind of pool from which it can allocate later bytes much more quickly (i.e. exactly what boost::fast_pool_allocator does).
That's only a guess but it seems like the kind of strategy tht a modern OS would probably employ. Just curious to know if that's what happens in practice?
"A problem well stated is a problem half solved.” - Charles F. Kettering
performance-wise, boost::fast_pool_allocator isn't particularly fast
the boost pool allocators are designed to be used when frequent uniform de/allocations of fixed size types are needed ( plus non-contiguous if fast_pool_allocator is used ). A different de/allocattion pattern will have a time and space penalty with respect to the usual heap allocators, so you should not use them interchangeably ( so, I don't think that the default allocator employs any free-list based pool mechanism for general de/allocations ).
Well... either way, with the vast amounts of memory available to a modern PC,
Come on, John. A tiny error in your custom allocation strategy, and you'll find that vast amount totally fragmented and wasted. Did you ever thought how many allocs/deallocs is done in modern OS in a second by all those hundreds of threads?
is a pooling strategy generally used these days or does each request still get treated as a one-off?
Pool is a way of organizing chaos to something controllable. Of course the control costs something. Of course universal solution cannot be optimal for any specific situation. Which means, when your particular task is too much specific, and the cost becomes too high, you have to invent some other strategy, less universal, but more efficient.
If I malloc (say) 3 x chars, surely the heap manager doesn't examine the heap each time to find the next available free byte?
Well, as far as I know CRT heap manager exactly does that.