Re: [boost] [Block Pointer] Up to 600% faster than Shared Pointer

On March 11, 2016 9:38:46 PM EST, Phil Bouchard wrote:

- I made the proxy explicit. Now it can be used 3 different ways:

1) Clothesline style:

block_proxy x; block_ptr<int> v(x, new block<int>(11)); block_ptr<int> w(x, new block<int>(12));

2) Root style:

proxy_ptr u(new block());

3) Container style (very easy to write containers now):

struct list : block_proxy { public: list() : root(*this) {} [...] private: block_ptr<node> root; };

I simplified the syntax of the first two examples, but this still seems complicated given the various components and ways to combine and use them. I don't even know the point.

- If we use fastblock<>() then the speedup can go up to 600% compared to shared_ptr<>:

That's yet another piece to the complexity equation.

- Once again all the examples can be found here: https://github.com/philippeb8/block_ptr/tree/master/example

benchmark.cpp seems flawed for numerous reasons. You measure usage of the make function through a function pointer. You don't eliminate cold cache effects on timing each variation. You are timing free store allocations and deallocations, which can have unknown side effects. You aren't accounting for code elision by the optimizer.

- And the pointer itself here: https://github.com/philippeb8/block_ptr/blob/master/include/boost/smart_ptr/...

block_proxy provides little or no safety. First, destroying can be changed through the public interface, so why bother with the accessor/mutator pair? Second, init() can be called with any pointer of the required type. Does that type enforce the right semantics? I don't know. (The comment refers to stack pointers by which, again, I think you mean pointers that may belong to an object and can be on the free store as well, so the comment is misleading.) The loop in block_proxy::release() seems odd. First, are you purposely avoiding C++11? Range-based for would be better. You could also use for_each() with a lambda. As it is, why both m and n? I'd make more comments, but your comments often don't match the functions they adorn and the code is too hard to follow on this small screen. (Long lines and excess whitespace don't help.) HTH ___ Rob (Sent from my portable computation engine)