Re: [Boost-users] Question about pool.
We use boost pool in our project and we found boost's pool may occupy too much memory. Say, if we need a block of memory which size is 1317B, boost's pool will allocate a truck of memory 5268B on a 32bits platform, leave 3951 bytes unused (it get worse on 64bits platform). I don't think it is necessary to allocate 5268B, for the sake of performance, only 1320B is enough for align. It should be resovled because pool is so important to many large application.
pool allocates several blocks of memory at once, then divvies them
out. Nothing is wasted. Or did you have something else in mind?
--
Cory Nelson
Hi Nelson, thanks for your reply.
According to the description of pool, it should be working like you
said. But actually it is not the same. Hereby, there are two cases
provided.
I think you will find two totally different results between them.
1. blocksize = 1316
Everything is ok. .
2. blocksize =1317
Disaster! You can notice the waste allocated memory. I just want case
2 to run like case 1.
Following is the code, you can check it.
1.
i: 0 need: 41(KB) alloc: 41(KB) waste: 8(B)
i: 32 need: 82(KB) alloc: 82(KB) waste: 8(B)
i: 96 need: 164(KB) alloc: 164(KB) waste: 8(B)
i: 224 need: 329(KB) alloc: 329(KB) waste: 8(B)
i: 480 need: 658(KB) alloc: 658(KB) waste: 8(B)
i: 992 need: 1(MB) alloc: 1(MB) waste: 8(B)
i:2016 need: 2(MB) alloc: 2(MB) waste: 8(B)
i:4064 need: 5(MB) alloc: 5(MB) waste: 8(B)
i:8160 need: 10(MB) alloc: 10(MB) waste: 8(B)
2.
i: 0 need: 41(KB) alloc: 164(KB) waste: 123(KB)
i: 32 need: 82(KB) alloc: 329(KB) waste: 246(KB)
i: 96 need: 164(KB) alloc: 658(KB) waste: 493(KB)
i: 224 need: 329(KB) alloc: 1(MB) waste: 987(KB)
i: 480 need: 658(KB) alloc: 2(MB) waste: 1(MB)
i: 992 need: 1(MB) alloc: 5(MB) waste: 3(MB)
i:2016 need: 2(MB) alloc: 10(MB) waste: 7(MB)
i:4064 need: 5(MB) alloc: 20(MB) waste: 15(MB)
i:8160 need: 10(MB) alloc: 41(MB) waste: 30(MB)
here is the sample code:
#include <iostream>
#include
On 9/6/07, 蹬三轮的
According to the description of pool, it should be working like you said. But actually it is not the same. Hereby, there are two cases provided. I think you will find two totally different results between them.
Okay, I have found the problem. pool::alloc_size seems to be a least
common multiple of sizeof(void*) and your chunk size.
Assuming sizeof(void*) is 4,
In the case of 1316, this comes to 1316. In the case of 1317, this
comes to 5268, or 4 times the requested size which is what you are
seeing. This seems incorrect.
I have not tested this, but on line 183 of boost/pool/pool.hpp, change
return details::pool::lcm
On 9/6/07, 蹬三轮的
wrote: According to the description of pool, it should be working like you said. But actually it is not the same. Hereby, there are two cases provided. I think you will find two totally different results between them.
Okay, I have found the problem. pool::alloc_size seems to be a least common multiple of sizeof(void*) and your chunk size.
Assuming sizeof(void*) is 4, In the case of 1316, this comes to 1316. In the case of 1317, this comes to 5268, or 4 times the requested size which is what you are seeing. This seems incorrect.
I have not tested this, but on line 183 of boost/pool/pool.hpp, change
return details::pool::lcm
(requested_size, min_size); to:
return std::max(requested_size + (min_size - 1) & ~(min_size - 1), min_size);
This should fix your size problem while still keeping the size aligned on pointer-sized boundaries, which I believe was the original intention of the author. Does Stephen Cleary even monitor this list to comment? I would also like to hear a comment from Stephen. Anyway, reading
Cory Nelson 7.9.2007 5:13: through "concepts" in pool docs, it seems that the least common multiple is used to ensure proper alignment (if you ever got a SIGBUS, you'll want to avoid unaligned memory access). So beware.... Cheers, Filip
participants (3)
-
Cory Nelson
-
Filip Konvička
-
蹬三轮的