From: Christian Thäter (chth_at_[hidden])
Date: 2001-07-11 23:43:44
I was up to write my own 'shared_ptr' class for resource-sharing as it came in mind that i first look up what boost provides. So I found the boost smart_ptr's. Mhmm ... but stop ... whats that .. doh .. not the semantics i need, resetting and assigning a boost::shared_ptr doesn't update all pointers which belong to the object, mhm .. and it might throw a exception. Ok, there we go, i took the boost interface and hacked my own idea by using a cyclic single linked list, instead a reference counter.
How about the performance? Just curious I wrote a very small benchmark.
Updating the entire pointer-chain takes O(N) time for N pointers, boost::shared_ptr uses O(1) algos but calls 'new long' and needs to dereference the reference-counter sometimes, so "How many (chain-) dereferences weighting an average 'new long' call?". Also it's clear that the 2 beasts are not really compareable because of the diffrent semantics. I just run it, see some hand-drawn chart at http://home.t-online.de/home/cehteh/sp.png . Well, the tests are more biased to the boost::shared_ptr cause they use up to 128 copies of the pointer, there you should not compare an O(1) with an O(N) algorithm. How many copies of a shared_ptr do You usually use on a average? I need them for 2 to 8 copies usually. I want to propose this new pointer-class for the boost/smart_ptr.hpp library either by a new name or by modifying boost::shared_ptr (has anyone code which would be broken by the semantic change?).
Ah here are my test-sources: http://home.t-online.de/home/cehteh/sp.tar.gz
Short conclusion of features:
never allocates memory by itself
new semantics: reset() and operator= affect all pointers according to the resource
predictable timing behaviour
faster than boost::shared_ptr when used with less than lets say 8 to 16 copies
dtor, copy, assign and use_count using O(N) algorithms instead O(1) like boost::shared_ptr
which decreases performance when many copies are in use.
dereferencing the shared_ptr itself is the same with both kinds.
By using a double linked list, the dtor can have O(1) complexity too (space tradeoff),
changing copy and assign to O(1) is not trivial because of the changed semantics
PS: will boost use exception-specifications in the future, because some compilers honor it when optimizing?
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk