From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2006-01-04 14:34:52
David Maisonave wrote:
> "Thorsten Ottosen" <tottosen_at_[hidden]> wrote in message
>>Test performance for initializing and copying container of pointers.
>>vector<copy_ptr<Shape> > 1.42 s
>>boost::ptr_vector<Shape> 0.81 s
>>vector<cow_ptr<Shape> > 0.13 s
>>But this test is a bit unfair: we create copies of the vector, but we
>>never mutate that copy. A fair test would mutate all the elements.
> The cow_ptr is like a clone pointer and a shared pointer put together.
> It shares the pointer, until an attempt is made to access it via
> non-constant operator-> or operator*.
> If non-constant access is made, then it checks to see if it's reference
> counter is larger then one. If so, it then performs the deep-copy, and
> releases the reference count.
> This is very efficient, because there's a good chance that the using
> code will never access all or any of the container objects in a
> non-constant manner.
well, if no objects are being mutated, we don't have to make a copy.
In practice I don't have a good estimate of how much data is touched,
but imgaine that it can easily be it all. In that case I expect
ptr_vector to win again (like it did in the other three categories).
> The difference in efficiency will show up even more, when you have a
> more complex type that takes more time to construct.
right, the above results has another string data member of size 100.
> The test code uses
> a simple Shape class, which doesn't have much to it, but if you added
> more data members, and made the construction more complex, then the
> above test will be drastically different and it would show cow_ptr
> having a very high performance ratio.
it would also increase the likelihood that we would mutate the objects.
> By the way, I believe you could add this type of COW logic to the
> existing boost pointer containers, and increase their efficiency.
It depends somewhat of the situation at hand AFAICT.
> But there is an overhead to this logic,
right. ptr_vector uses vector<void*> internally to minimize binary size
too. and runtime-space-wise, its optimal. whether that matters depends
on the situation.
> and you might have notice that
> some of the test show copy_ptr out performming cow_ptr.
> You could consider adding a policy option to the boost pointer
> containers, that would allow choosing between COW method and
> Clone-Always method.
perhaps, but I do fear such a thing would greatly complicate the
I also have some concerns on performance of COW in multi-threaded
As for cow_ptr requiring copy-semantics, then I think that is a
very poor idea. It must be possible to call new_clone() or similar.
Good luck with the article, let us know when it is done.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk