Moving live objects is very dangerous, and I think it would cause a lot of problem on threads' synchronization. 2007/5/8, Michael Gopshtein <mgopshtein@gmail.com>:
According to documentation to "Pool" library, it is intended to be used "when there is a lot of allocation and deallocation of small objects".
In our product we also use such pool for allocation of "normal" - heavier objects. In such case we can't benefit from significant improvement in memory consumption per object (overhead of malloc's internal structure relative to used size of the object), but the allocations themselves are much more efficient.
Additional advantage is memory fragmentation - all objects in the pool reside in continuous memory blocks.
The main problem with such usage is, in our case, that the pool never "returns" memory to the system, unless it's released. For example, if I use the pool for allocation of Event objects, and at some point of time I had 10000 concurrent events, the pool will occupy all that memory while the process is alive, even if for most of the time I use a small portion of it.
As a solution I was thinking about adding a "defragment" function to memory pool, which will compact it by moving live objects to free cells at the "beginning" of the pool. Such feature can be implemented with help of additional "index" table of pointers. Of cause, instead of returning pointer to allocated object, the pool will return a wrapper object, actually pointing to that index table (for which separate "classical" pool can be used).
So, the first question is: do you think such feature will be helpful?
If yes - please share your thoughts regarding suggested and/or other implementations?
Michael
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost