Re: [boost] [Block Pointer][Container] Works - Take 2

Subject: Re: [boost] [Block Pointer][Container] Works - Take 2
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-03-05 10:30:17

On 03/05/2016 05:30 AM, Peter Dimov wrote:
> Phil Bouchard wrote:
>
>> - I removed the usage of an allocator.  Now there is no need for any
>> allocator anymore.
>
> I'm not sure I see how this would work. If you have
>
> void f()
> {
>     vector<block_ptr<T>> v;
> }

You are close to a valid point.  Although this case works:
https://github.com/philippeb8/block_ptr/blob/master/example/block_ptr_test2.cpp#L125

If you have a cycle on the heap that is not owned by a root pointer from 
the stack then I think the memory blocks will still be deleted.

If you look at how it is implemented, when the number of pointers from 
the stack reaches 0 or if it is already 0 then all memory blocks will be 
wiped out:
https://github.com/philippeb8/block_ptr/blob/master/include/boost/block_ptr.hpp#L484

I thought there would be a leak there but thinking about it twice I 
believe it should be fine.  I'll try some other strange use case...

>     block_ptr<vector<block_ptr<T>, block_allocator<T>>> v2;
>
> for the second case allows you to distinguish between the two.

Ideally I could do that but the implementation of the allocator for 
containers turns out to be a real challenge.

The code is much cleaner "but" since it allocates more proxies, despite 
using the fast pool allocator, that still slows down the overall 
performance:

make:
auto_ptr:                   26164754 ns
shared_ptr:                 27554248 ns
block_ptr:                 144391600 ns

new:
auto_ptr:                   22210062 ns
shared_ptr:                 46869206 ns
block_ptr:                 138204822 ns

block_ptr<> is now 300% slower than shared_ptr<> for this type of benchmark.

Regards,
-Phil