Here's what happens: Inbetween every loop iteration, for the correct code (stack & heap), the BigObject has its destructor called, then the constructor is called again, zero filling the array.

For the pool, it calls "reset", which does nothing. What should be done is calling the destructor in place, then the constructor in place. Otherwise you're not really doing the same thing as the other allocations.

Object pools are better than heap allocations, but they are never faster than stack allocation (which is virtually free).

TL;DR: The author is cheating, the benchmark is plain wrong.

With pools, you pay an up-front cost for the faster allocation later. So a better way to arrange the benchmark would be showing off frequent pool creation and deletion of objects.

It really depends on how heap allocation is implemented, so it's hard to compare. By using memory pools, you can allocate a huge block of memory at once from the OS (a small initial cost), and lazily initialize the values. Which brings you: 1. Cache locality. 2. A lot less fragmentation.

I'd rank it as:

1. Stack allocation (essentially free)

2. Memory pool (a small hit every once in a while)

3. Heap allocation (significant overhead compared to the other ones)