Have you ever obtained a significant speedup by using boost::pool?

Question

I've played with boost::pool a few times in places where it seemed to me I was seriously hammering the heap with a lot of object "churn". Generally I've used boost::object_pool, or boost::pool_alloc as an STL template parameter. However the result is invariably that performance is virtually unchanged, or significantly worsened.

I'm curious to hear of any success stories with it.

What sort of things should I look for in profiling output which might indicate boost::pool is likely to help ?

Is it just actually pretty hard to improve on good old malloc ?

Answer 1

Memory pools are most effective imo for transaction style processing where you can allocate to the pool and then when the transaction is done, just dump it into oblivion. The real speed up isn't that each allocation is going to be much faster its that you will have near zero memory fragmentation in an extremely long running application.

In sort, it sounds like your applications do not warrant using memory pools

Answer 2

Yes, 500% speed increase. The application (rather stupidly, but sometimes you have to work with what you got) copied elements from 1 std::map to another in a loop (there was some decision making in the loop), and the resulting allocations on multithreaded/process servers resulted in heap contention. I added the boost pool as an allocator on the second map and the result was a 500% increase in application execution speed.

Answer 3

Blind optimizations are not good. Try to use google memory allocator, you don't even need to recompile your application. You can find what you need to know in here:

http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html

Gaetano

Answer 4

You might want to track down your performance problems to memory allocations first before you start to optimize for that.

So, narrow down your profiling to pinpoint the location of the problem. This can be lots of calls to the same code that might not take long when only called once.