On 02/07/2016 07:59 AM, Bjorn Reese wrote:
On 02/06/2016 10:05 PM, Phil Bouchard wrote:
But it's like comparing apples with oranges because shared_ptr is a smart pointer and block_ptr really is a memory manager there to replace the garbage collector.
The documentation is doing that apples and oranges comparison when it claims that the performance of block_ptr "is comparable to shared_ptr". Furthermore, that claim is questionable as the benchmarks show that block_ptr is slower by several factors. If the benchmarks are unfair, then you should design better ones.
Ideally the pool routines would offer a faster ordered_malloc() or the main memory manager would offer some is_from() function because I need to draw the line between the heap and the stack at run-time.
The presentation claims "Constant complexity O(1) for all operations". Looking at the code I can see several loops (e.g. release() or redir() in block_header) so destruction does not appear to be constant.
You're right, destructions can be O(n) and assignments can be O(log(n)) worse case scenarios. I need to correct the documentation.
I also have an unrelated comment about the documentation: the Reference section is very confusing. It lists lots of detail functions rather than the public API.
Unless the counter is intrusive but that's the thing because block_ptr abstracts all of this and it is much less confusing to the end developer. And I'm not sure how intrusive counters can deal with multiple / virtual inheritance.
Which intrusive counter are you talking about? Are you thinking of intrusive_ptr<T>?
I was thinking intrusive_ptr<> and make_shared<> which have both the same optimum performance: http://www.boost.org/doc/libs/1_40_0/libs/smart_ptr/make_shared.html But while I don't see how intrusive_ptr<> deals well with multiple inheritance, make_shared<> & shared_ptr<> needs to manage 2 pointers; one for reference count and one for the pointed object. block_ptr<> also manages 2 counters but it takes care of cyclic references.