Good experience with boost memory pool
With increasing number of source code to compile, the compiler I maintain becomes unacceptable slow. After profiling the code with AQTime, I found about 30% percent CPU is used by malloc(), and half of them are for tree node allocation(fixed size).
After testing the performance of boost memory pool, I simply replaced malloc() with boost::object_pool::malloc(). The result is great, it almost eliminated the cost of tree node allocation. The total amount of time used for malloc is down to 13%. Still plenty of room for improvement, but the performance is at least acceptable.
There is one thing to remember: boost::object_pool is designed for "allocate many objects and then destroy all of them" type of scenario, so freeing memory from the pool can be very slow. For example, at the beginning I also replaced free() with boost::object_pool::free(), which make the performance even worse: boost::simple_segregated_storage::find_prev() and boost::simple_segregated_storage::nextof() start to take over all the CPU. So I do not do free anymore and simply let ~object_pool() to release the memory. This works perfect for my compiler, but may not be good for other applications.
After testing the performance of boost memory pool, I simply replaced malloc() with boost::object_pool::malloc(). The result is great, it almost eliminated the cost of tree node allocation. The total amount of time used for malloc is down to 13%. Still plenty of room for improvement, but the performance is at least acceptable.
There is one thing to remember: boost::object_pool is designed for "allocate many objects and then destroy all of them" type of scenario, so freeing memory from the pool can be very slow. For example, at the beginning I also replaced free() with boost::object_pool::free(), which make the performance even worse: boost::simple_segregated_storage
0 Comments:
Post a Comment
<< Home