patterncppMinor
Smart pointer memory pool
Viewed 0 times
smartmemorypoolpointer
Problem
I'm using a third-party library which utilizes
The problem is that I need to allocate many objects and I have detected that the allocation and deallocation is rather resource-demanding. So I thought I should utilize a smart-pointer memory pool to reduce the overhead.
The solution is to utilize
Any thoughts, comments or pretty much anything would be appreciated.
boost::shared_ptr for memory management.The problem is that I need to allocate many objects and I have detected that the allocation and deallocation is rather resource-demanding. So I thought I should utilize a smart-pointer memory pool to reduce the overhead.
#include
template
class shared_ptr_pool
{
boost::shared_ptr pool;
size_t avail = 0;
public:
boost::shared_ptr make_shared()
{
if (!avail)
{
pool = boost::make_shared(pool_size);
avail = pool_size;
}
return boost::shared_ptr(pool, &pool[--avail]);
}
};The solution is to utilize
make_shared for arrays and the shared_ptr aliasing constructor. The solution in inherently thread-unsafe, but for my needs that is okay.Any thoughts, comments or pretty much anything would be appreciated.
Solution
Per the comments, this isn't really a "pool" because things don't go back into it when you're done using them. It's just an "incremental allocator" that does allocation in "chunks". A better name for it might be
Given that
This would even allow you to provide a member function for modifying the chunk size on the fly, in case maybe your code could detect that its particular workload demanded a bigger chunk size.
The actual code implementation looks fine to me; nothing to complain about there. :)
You might be pleased to (or, you might already) know that
shared_ptr_chunk_allocator (and chunk_size instead of pool_size).Given that
pool_size is used only on the codepath that also allocates memory (so it's not a super speed-critical path where one more memory load would hurt performance), and shared_ptr_pool has non-static data members (so there's no harm in adding one more non-static data member), surely it would make more sense to make pool_size a runtime parameter to shared_ptr_pool's constructor.// your current code:
shared_ptr_pool pool;
// versus my suggestion:
shared_ptr_pool pool(16);This would even allow you to provide a member function for modifying the chunk size on the fly, in case maybe your code could detect that its particular workload demanded a bigger chunk size.
if (memory_usage_low && still_spending_lots_of_time_in_allocation) {
pool.set_chunk_size(pool.chunk_size() * 2);
}The actual code implementation looks fine to me; nothing to complain about there. :)
You might be pleased to (or, you might already) know that
std::shared_ptr is part of the Library Fundamentals v1 Technical Specification, which I think means it ought to be coming to C++1z. However, it's not in the working draft yet as of N4567 (November 2015).Code Snippets
// your current code:
shared_ptr_pool<myclass, 16> pool;
// versus my suggestion:
shared_ptr_pool<myclass> pool(16);if (memory_usage_low && still_spending_lots_of_time_in_allocation) {
pool.set_chunk_size(pool.chunk_size() * 2);
}Context
StackExchange Code Review Q#45161, answer score: 5
Revisions (0)
No revisions yet.