[Development] Proposal for "container-oriented deterministic memory manager"

Phil Bouchard philippeb8 at gmail.com
Sat Jan 7 01:17:55 CET 2017


On 01/05/2017 06:44 PM, Phil Bouchard wrote:
> On 01/05/2017 07:26 AM, Phil Bouchard wrote:
>>
>> Simon was mentioning that it would be preferable having root_ptr with an
>> underlying mechanism to select memory pools based on the type allocated
>> or the frequency of the allocation made.  I don't see how it could be
>> further optimized.
>
> After reading the following optimized memory pool documentation:
> https://github.com/cacay/MemoryPool
>
> I just realized how obvious it is.  You just add some timer to determine
> the frequency, you measure the speed of the allocation requests and you
> "adapt" the memory chunks you allocate that will be later subdivided
> into the sizeof the type of the object.  All of this type-oriented.
>
> So if you allocate 1,000,000 integers a second then larger memory blocks
> of sizeof(int) * 1000000 * CONSTANT will be allocated at once.
>
> I am cross-posting this message with the Boost mailing list because it
> is so evident.

Just to conclude I did try the attached benchmark and I get the 
following on a x86_64 @ 2.40 GHz:

0: 61331143.40263957 allocations / second
1: 63644162.93924019 allocations / second
2: 177628727.5388474 allocations / second
3: 179850939.5413082 allocations / second
1 / 0: 103.7713621632905% boost
2 / 1: 101.2510431354494% boost

So the fast_pool_allocator is already pretty fast and I can only get a 
1% speed boost by allocating big memory blocks.  So it doesn't look like 
there is any way to make the fast_pool_allocator any faster.


Regards,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool-benchmark.cpp
Type: text/x-c++src
Size: 1561 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170106/949ffaa1/attachment.cpp>


More information about the Development mailing list